Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

DBIx::Class Object Caching

by Herkum (Parson)
on Jul 12, 2011 at 15:34 UTC ( #913939=perlquestion: print w/replies, xml ) Need Help??

Herkum has asked for the wisdom of the Perl Monks concerning the following question:

Does DBIx::Class handle caching of objects? Example: I do this,

my $album1 = $schema->resultset('Album')->find(14); my $album2 = $schema->resultset('Album')->find(14);

Are these two objects going to be the same object or are they two separate objects. Basically I don't want to worry about race conditions between them.

Replies are listed 'Best First'.
Re: DBIx::Class Object Caching
by chrestomanci (Priest) on Jul 12, 2011 at 16:00 UTC

    I am not sure about the the example you have given, (Where the first row object remains in scope when the second call is made) but in the general case they are likey to be different.

    Once a row object goes out of scope perl will Garbage collect it. If you want it back again you need to do another find, and DBIx::Class will look in the database, and inflate the row into a fresh instance of the class.

    As far as I know DBIC does no caching behind the scenes of infated rows. I dare say that the developers of DBIC consider this a feature, as otherwise you could find yourself holding a stale object if another user of the databse changes the row. In any case if DBIC was caching row objects it would need a memory management system with weak references to avoid using up all your memory when you iterate over the rows of a large table.

      The point of caching the object has two primary uses,

      1. To prevent race conditions.
      2. Prevent unnecessary overhead querying the database.

      Basically, if I cannot have consistency between the same object in the same script, memory management MAY be an issue, but I have already created a problem where the objects can easily fail the ACID test. Which is where a lot of relational databases get their utility from.

        I am just another user of DBIx::Class, not a developer, so there is no point telling me that the design might be wrong.

        In what situation do you anticipate a race condition? To me that implies two different processes with separate connections to the database, so it would be meaningless for them both to see the same object.

        In the case of reducing the overhead of multiple database queries, in my experience it is not a problem. If you are using the same row object twice close together (in time or in code terms), then it is easy enough to keep it in scope. If the two uses of the object are a long time apart, or in distantly related parts of program then it would be better to do fresh database queries to avoid the risk of stale objects. Remember that the database will be caching the rows, so if it has not changed between accesses, then the cost of retrieving it a second time will be small. Why put code to check if it has changed in DBIC as well, when it is already in the back end database.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://913939]
Approved by Corion
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2020-09-20 07:28 GMT
Find Nodes?
    Voting Booth?
    If at first I donít succeed, I Ö

    Results (120 votes). Check out past polls.