possible improvement of Live_Objects cache

[prev] [thread] [next] [Date index for 2005/06/27]

Hi,

I have a question about object caching in Class::DBI using %Live_Objects
in Class::DBI->_init(). I came across a situation where it seems that
caching worked against me. That situation is as follows (where one CD
has many Tracks):

#Get some tracks (how the tracks are retrieved is not relevant).
#The Track objects will be stored in the cache with
#  all essential fields *and* the related CD objects will be
#  stored with only their id.
my @tracks = My::Tracks->find_some_tracks();

#Get some CDs
#Here, the cds with all essential fields are retrieved from the
#  db with some query, but the content is ignored for cds of
#  which an (empty) object already exists in %Live_Objects.
my @cds = My::CDs->find_some_cds();

#Even if CD.name is an essential column and the information has
#  just been retrieved in the previous statement, Class::DBI
#  will do a query for the essential columns of each cd of
#  which a track was retrieved in the first statement.
my @cd_names = map( $_->name, @cds );

Note that if order of the first two statements would have been reversed,
this problem would not have occurred. The example above is a bit
over-simplified, but you can imagine situations where some_cds() depends
on the result of find_some_tracks(), so the order cannot be reversed.

The following fix reduced the number of queries in my application a lot,
but I am not sure it works in all situations:

< # don't store it unless all keys are present
< if ($obj_key && $Weaken_Is_Available) {
---
> # don't store it unless all keys are present
> if(defined($obj = $Live_Objects{$obj_key}) ) {
>     if( scalar keys %$obj == scalar @primary_columns ) {
>         $obj->_attribute_store(%$data);
>     }
> } else {

I am not very experienced in the Class::DBI internals. What do you
think? Would this always improve the performance of Class::DBI or are
there possible conflicts?

Thanks, Jasper