[Dbix-class] Lazy Columns

[Peter Rabbitson]

Ovid 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.
> 
> While you don't want to force lazy columns on every query, being able to specify columns lazily *per search* would be lovely, but it doesn't quite work.  I can say:
> 
>     my $rs = $schema->resultset($some_class)->search(
>         undef,
>         { columns => ['title'] },
>     );
> 
> Except that I'm a nice chap and mail this off to my brother and when he opens it up, the first thing he sees is that the $object->wall_o_text attribute returns undef and he doesn't know if that's because it's undef or because I didn't ask for it in my "columns =>" (actually, he can know if he mucks about in the $rs, but it's painful).

Or he can use http://search.cpan.org/~frew/DBIx-Class-0.08121/lib/DBIx/Class/Row.pm#has_column_loaded

> 
> I'd like lazy column loading.  So imagine I have a table with columns named 'a' to 'z' and I want to fetch everything except columns 'h','u','g' and 'e'.
> 
>     my $rs = $schema->resultset($some_class)->search(
>         undef,
>         { defer_columns => [ qw/ h u g e / ] },
>     );
> 
> (Or "{ '-columns' => [ qw/ h u g e / ] }"? I like that syntax, but it's not really the opposite of the 'columns' or '+columns' feature.)
> 
> And later on:
> 
>     while ( my $object = $rs->next ) {
>         if ( 'aye' eq $object->a ) {
>             say $object->$_ for qw/ h u g e /;
>         }
>     }
> 
> The idea is that:
> 
>   * $some_class must have a primary key defined
>   * deferred columns must not be primary key columns
>   * If a deferred column is requested, query is re-executed, asking for just the missing columns, using the PK as a constraint
> 
> I'm sure there are serious pitfalls here, but we have an issue at work where deferring the loading of some columns increases SQL response time so much that issuing separate queries for every row to fill in missing data is faster.
> 

It's not very hard, but extremely tedious to make this work transparently
the way you want. Come to #dbix-class to discuss some preliminary ideas you
have (and get them shot down in flames :D)