Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re^4: Maybe database tables aren't such great "objects," after all ...

by JavaFan (Canon)
on Mar 28, 2011 at 12:45 UTC ( [id://895893] : note . print w/replies, xml ) Need Help??


in reply to Re^3: Maybe database tables aren't such great "objects," after all ...
in thread Maybe database tables aren't such great "objects," after all ...

How do you maintain transactional integrity in a situation where Perl objects reference multiple tables and different Perl objects might have overlapping table references? It seems to me that sometimes, you want to make sure that a number of Objects being updated result in the database tables being updated atomically and not understanding the impact on the underlying tables might lead one to believe this is being done when it's not.
Then your encapsulation/abstraction is broke^Wsub optimal.

Your example seems to come from a notion that still has a very tight coupling between data layout and Perl data structures.

Conversely, you might only want to operate on a single object and have that update the table without waiting on operations on associated objects.
"The table"? What table? Again, loosen the idea there should be a mapping between tables and objects (although you probably mean rows and objects (or tables and classes)).