Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re^2: Reloading CDBI objects from database elegantly

by exussum0 (Vicar)
on May 19, 2005 at 21:56 UTC ( #458809=note: print w/replies, xml ) Need Help??

in reply to Re: Reloading CDBI objects from database elegantly
in thread Reloading CDBI objects from database elegantly

Are you saying that some ORMs let you,
  1. Create an object.
  2. Store it.
  3. Retrieve it into some variable a.
  4. Retrieve it again into some variable b.
  5. A change to a won't change b?

Give me strength for today.. I will not talk it away..
Just for a moment.. It will burn through the clouds.. and shine down on me.

  • Comment on Re^2: Reloading CDBI objects from database elegantly

Replies are listed 'Best First'.
Re^3: Reloading CDBI objects from database elegantly
by perrin (Chancellor) on May 20, 2005 at 04:00 UTC
    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.

      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?


      Give me strength for today.. I will not talk it away..
      Just for a moment.. It will burn through the clouds.. and shine down on me.

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://458809]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2018-07-15 23:19 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (327 votes). Check out past polls.