Re^2: DBIx::Class Object Caching

in reply to Re: DBIx::Class Object Caching
in thread DBIx::Class Object Caching

The point of caching the object has two primary uses,

To prevent race conditions.
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.

Comment on Re^2: DBIx::Class Object Caching

Replies are listed 'Best First'.
Re^3: DBIx::Class Object Caching by chrestomanci (Priest) on Jul 12, 2011 at 18:35 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^3: DBIx::Class Object Caching
by chrestomanci (Priest) on Jul 12, 2011 at 18:35 UTC

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.

[reply]

In Section Seekers of Perl Wisdom