[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