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

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.