Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: DBIx::Class Object Caching

by chrestomanci (Priest)
on Jul 12, 2011 at 16:00 UTC ( #913949=note: print w/ replies, xml ) Need Help??


in reply to DBIx::Class Object Caching

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.


Comment on Re: DBIx::Class Object Caching
Re^2: DBIx::Class Object Caching
by Herkum (Parson) on Jul 12, 2011 at 16:16 UTC

    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?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://913949]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (10)
As of 2014-09-16 21:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (50 votes), past polls