Re: loading many objects from one query

[prev] [thread] [next] [Date index for 2004/09/14]

On Mon, Sep 13, 2004 at 10:22:37PM -0400, Perrin Harkins wrote:
> Andrew Pimlott wrote:
> 
> >One situation in which I think Class::DBI may be lacking is when you
> >need to access a large number of database entities, so many that you
> >can't afford to load them on demand.  I'd like to write a big query that
> >joins many tables, then use the results of the query to populate many
> >Class::DBI objects of various types, as well as all of the relationships
> >between them (so I never have to go back to the database to use these
> >objects).  For bonus points, it should also be possible to force
> >fetching the rows of this big query as needed, instead of all at once.
> 
> The ability to construct objects from data that you fetched on your own 
> is already there, in the form of the method "construct".

And here's an example you posted yourself a while ago:

sub retrieve_with_bar {
    my ($class, $id) = @_;
    my $sth = $class->sq_get_both();
    $sth->execute($id);
    my $row = $sth->fetchrow_arrayref();
    my $foo = Foo->construct({
                              id    => $row->[0],
                              other => $row->[1],
                             });
    my $bar = Bar->construct({
                              id    => $row->[2],
                              other => $row->[3],
                             });
    $foo->{'_bar_object'} = $bar;
    return $foo;
}

> The tricky 
> part would be making the relationship accessors use an in-memory cache 
> instead of the database.  I would suggest doing that part by writing 
> your own relationship type that looks at a cache first and then calls 
> the normal has_many relationship code if it doesn't find anything.

Umm. Seems like a bug/limitation of the caching code that construct() isn't
integrated with it in some way. Currently all uses of sth_to_objects()
don't consider the cache at all.

Tim.