Re^3: Reloading CDBI objects from database elegantly

[perrin]

All of the perl ones work that way, except for the latest version of Class::DBI which does some tricks with an index of loaded objects and weakrefs to avoid this. And that has caused so many user complaints that I'm hoping to turn it off in the next release.

ORM or not, once you retrieve data from the database and hold it in a variable, it has no way of knowing that the underlying database has been changed. This usually doesn't matter since the data is kept in variables for only a short time. Where it does matter, people have to use locking schemes to deal with it.

[exussum0]

Thanks for the info on Class::DBI.

But it really depends on the ORM. Having delt with ones inside and outside of perl, EJB and I think Hibernate both support multiple instances of an object, but modifying one means you modify the other for persistable things. Hibernate doesn't do it as thoroughly as EJB.

I'm really surprised it has caused complaints. What have you been told?

-s

[perrin]

There are a couple of different concepts in play here. The OP was having trouble with changing things inside the database and not having the already loaded object notice. No ORM with objects that maintains state in memory for even a very brief period of time is safe from this. The only way to totally avoid it is pessimistic locking. This is even true for basic DBI and JDBC apps that put the data in variables for any period of time.

The other concept is the one you're talking about, where multiple objects that refer to the same data in the database reflect each other's changes while in memory. A good ORM should at least support this as an option. It gets pretty tricky when you're in a multi-process environment though, and pretty much impossible on multiple machines without massive overhead.

The problems people have with Class::DBI stuff are all related to scoping problems with Perl. I implemented the Class::DBI "object index" system (with help from Tim Bunce) using weak references so that the index itself does not prevent garbage collection when things go out of scope. However, it turns out that MANY people have scoping bugs in their code where objects do not get collected at the point they were expected to, and when they load them again they get the version still in memory, which the weakref index knows about even though they thought it was gone. Some people have posted code where it's pretty hard to see why the object has not gone out of scope yet.