[Dbix-class] Prefetch question
moseley at hank.org
Thu Dec 17 14:30:27 GMT 2009
On Thu, Dec 17, 2009 at 2:09 AM, Bernhard Graf <dbic4 at augensalat.de> wrote:
> Charlie Garrison schrieb:
> > Note, Bill said Class::DBI, not DBIx::Class. They are completely
> different packages.
> Ew - you are right! Thanks.
> Does that mean DBIx::Class doesn't have something similar?
Not that I'm aware of and probably not very desirable. You could look at
DBIx::Class::Cursor::Cached but I assume that's a different beast.
I'd really be interested in benchmarks between your prefect and not. Isn't
it just commenting out your prefetch?
Speaking of CDBI, and something I mentioned in the past, what I'm still
trying to get used to (and clean up in our app) is that if you have a list
of, say, music CD objects and want to create links to each CD's artist (via
its id) then just $cd->artist->id does a fetch to the database for something
we already know from the CD object.
The prospect of renaming all our F.K.s to artist_id and creating artist as a
relationship is, well, not possible. Yes, there's get_column(), but it's
hard to remember and isn't very abstract. $c->uri_for( '/artist/edit',
cd.artist ) just seems like the right abstraction. I could prefetch, but
then I'm doing a join that's not needed.
Perhaps that is not a great example because when linking to artist I would
probably want to display the artist name an a prefetch would be corect.
But, it does happen often that we need the id w/o any other column data from
that related table.
That worked in CDBI because when the CD object is created the related artist
object is also created with just the id attribute filled in (the rest of the
attributes were lazy loaded if not prefetched). But, maybe the argument for
not doing that is the expense of creating the related objects when they
might not always be used. Creating objects is faster than going back to the
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the DBIx-Class