Re: Constructing objects in multiple CDBI classes w. single SELECT

[prev] [thread] [next] [Date index for 2005/03/02]

From: Perrin Harkins
Subject: Re: Constructing objects in multiple CDBI classes w. single SELECT
Date: 23:25 on 02 Mar 2005
On Wed, 2005-03-02 at 18:05 -0500, Michael Graham wrote:
> There are two parts to this problem: the first is how to specify and perform
> the search, and the second is how to create the many related CDBI
> objects as a result of the search.

Usually it's just the first.  People often want to do searches that
involve a join, but only result in a single object type.  Getting
multiple object types back usually means you are writing a report, and
potentially shouldn't be using Class::DBI for it.  However...

> (I belive it's one query per artist, one per album, and
> one per track.  More maybe?)

Depends on what columns you access and which of them are in the
Essential column group.

> When I've had to deal with this issue in the past, I've bypassed
> Class::DBI entirely and used set_sql with $sth->fetchall_arrayref({}) to
> get a list of hashrefs instead.

That's what I would recommend.

> But then I had trouble keeping track of which parts of my code used
> Class::DBI objects and which parts used hashrefs...

The downside of optimization...

> In other words, I'm making Class::DBI's list accessors behave the same
> way as Class::DBI's scalar accessors:  if the data is already stored in
> the object, return it and don't hit the database.
> 
> My question is: could this feature be added to
> Class::DBI::Relationship::HasMany, or should I make a new kind of
> relationship?  Or is there a better way to accomplish this?

What you're talking about is caching, and it's fairly tricky to get
right for multi-process environments.  I would say it's safe enough to
cache them for the length of a single web request, but caching them for
the life of the object may not work for people using Class::DBI in a
long-running script, or with volatile data.  I think anything like this
should be optional.

> If I'm going to create a generalized query mechanism, how can I figure
> out how the classes are related to each other?  For instance, how can I
> know that the relationship between Music::Artist and Music::CD is
> HasMany?

There is class data that will tell you this.  Look at the
Class::DBI::Relationship::* source code.

- Perrin

Re: Constructing objects in multiple CDBI classes w. single SELECT
Perrin Harkins 23:25 on 02 Mar 2005

Generated at 00:32 on 04 Mar 2005 by mariachi v0.52