[Dbix-class] Live object index support ported

[John Siracusa]

Matt S Trout wrote:
>> Does it help keep 2 objects that are really the same row in sync?  If
>> so, what is a good reason for even having 2 objects that refer to the
>> same row, in the same process at the same time?

It depends on how you're looking at the DB/object relationship. If the DB is
a persistence mechanism for your Perl objects, then it probably doesn't make
sense to have two objects that "refer to the same row" in memory
simultaneously.

If, OTOH, your objects are an abstracted way to insert, update, and delete
rows in the database, then it makes plenty of sense.  Here's a real-world
example that I've run across.

Imagine loading a row into an object, then modifying the object.  During the
course of modifying the object, you must make decisions about which
attributes to update and what to set them to.  Now imagine that one of these
decisions depends on an abstract function named check_foo().  You aren't
supposed to know or care what check_foo() does; you  only care about what it
returns.

Everything sounds fine...until you realize that, as part of its decision
making process, check_foo() may very well look at the state of the row from
which your object was loaded, and it may do so using the same DB/object
library that you're using.  If that's the case, then instead of seeing the
state of the row as it currently exists in the database, check_foo() will
see the state of the *partially modified* object in the process of being
updated.  Oops.

IME, when using a DB/object mapper as an abstracted means to read and modify
the database, "implicitly shared" objects are usually not appropriate, and
can be downright harmful.

-John