On Fri, May 7, 2010 at 2:30 AM, Ovid <[email protected]> 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 [email protected]
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
