|Just another Perl shrine
Re^5: Maybe database tables aren't such great "objects," after all ...by jordanh (Chaplain)
|on Mar 28, 2011 at 17:16 UTC
It still seems to me that sometimes you'd want to operate on a number of objects inside a single transaction and other times in different transactions.
This would expose the nature of the underlying database at a high level if you were to explicitly commit at a high level.
I think ELISHEVA makes a good point. To design these things, you'd need someone with excellent DB and Object knowledge, but I'm wondering if you might also need that kind of knowledge to use the Objects effectively.
Update: I'm probably talking nonsense here. I can't really think of where you wouldn't want to encapsulate the commits with the updates, although perhaps you could get some efficiencies by deferring them across object references. That could be built into the toolkit, too, if you were clever.