[Dbix-class] partial sth compatibility in ResultSet?

[Brandon Black]

On 4/26/06, Matt S Trout <dbix-class at trout.me.uk> wrote:
>           if (rs) { $result = $results->next }
>           else { $result = MyApp::Model::Foo::Bar->inflate_result(
>                    $c->model('Foo::Bar')->result_source,
>                    $results->fetchrow_hashref);
>                }
>
> >        # do things with row;
> >    }
> > }
>
> How about that?
>

Yeah, that's what I'd like to do in general.  Ideally I'd like to make
a little module that can be initialized with a $schema and adds a
->next method to all DBI sth's that does the inflate_result() you show
above.  The problem I ran into there was two-fold though:

1) You have to parse the statement to know what the source table name
for the sth is (which is then easy to convert into source/class names
via standard DBIC interfaces).

2) Some queries don't really map to a given source exactly, as they're
composed of many columns (and derived function results) from many
sources.

Another option [ for constructing an $sth->next module ] would be to
make a little temporary class in memory on the first fetch which just
has accessors for all of the keys in ->fetchrow_hashref, and return
objects of that class.  I wouldn't get all the other DBIC benefits,
but for my relatively simplistic (and temporary) read-only needs here
it would at least allow my $sth's to look like DBIC syntax-wise. 
Since the constructed classes would only differ in the list of
accessor names they contain, it would be easy to cache and re-use them
on that basis alone, too.

So far it's looking like I'll just mostly ignore this problem until I
get done with this phase and free up some time, at which point I
really want to work on the SQL::Abstract-related stuff so that I can
support these queries in the first place.

Just when I had gotten a lot of my older "big" queries converted, I
discovered that the newest features I'm implementing now have even
worse queries :)  UNIONs, sub-selects as from-items, complex join
conditions, and functions which must be used as from-items (in some of
the worst queries, multiple of the above are present) are what's
biting me mostly.

-- Brandon