[Dbix-class] Lazy Columns

Bill Moseley moseley at hank.org
Fri May 7 14:20:44 GMT 2010


On Fri, May 7, 2010 at 2:30 AM, Ovid <publiustemp-dbic at yahoo.com> wrote:

> Back in the glory days (cough) of Class::DBI, lazy columns really seemed
> like a good idea in the same way that you find yourself trying why that
> one-size-fits-all suit seemed like a good idea.
>

Class::DBI's column groups did seem to work ok, but it took a bit of tuning
to prevent lazy loading grabbing columns that you just didn't want to fetch.
 I had a CDBI subclass  I used during development that would alert me
whenever CDBI went back to the database just for this reason.  I used it to
tune my essential columns setting.

I like the DBIx::Class approach better where I explicitly set the column.
Still, I have wondered if DBIC should throw an exception if you try and
access a column that was not fetched from storage.

It's pretty easy, of course, to add methods so that $row->huge_column will
fetch huge_column in a separate query.

The thing I miss about CDBI is without lazy loading is $cd->artist->id goes
back to the database to fetch an id that is already known.  Of course it
does, but lazy loading prevented that in CDBI.  But, that's a minor trade
off and easily "fixed" by adding a artist_id method.

I've had to add some logic and column mapping for my API consumers that ask
for "cd.artist" and really want an "cd.artist_id".

IMO, at this point I think I like that non-lazy loading better, but would
like a "strict" mode to catch trying to access columns that were not fetched
(although Template Toolkit would hide those).


-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100507/a6d=
9bd1b/attachment.htm


More information about the DBIx-Class mailing list