[Dbix-class] more confusion about prefetch

[George Hartzell]

[possible bug w/ fix in ResultSet.pm, see case e) below]

I'm still wrestling with the problem described here:

http://lists.rawmode.org/pipermail/dbix-class/2006-August/002149.html

[I'm using DBIx-Class-0.06003]

I'm playing with the idea that using distinct => 1 in my query is
messing up the prefetching various has_many fields.

To experiment with the theory I decided to run the query as is, then
get the rn.id from the result of the query, and do a

  resultset->find({id => $rn->id()},
                  {prefetch => VARIOUSTHINGSGOHERE,
                  }

and see if I can figure out how to prefetch the rn, and its has_many
nodes and their has_many node_attrs and the rn's has_many controls and
their has_many control_attrs.

In other words, I'd like to grab an rn and pull out all its parts at
the same time.

Here are some things that I've tried:

a) This

   prefetch => 'nodes',

   runs to completion and does seem to prefetch the node records
   (based on watching the sql that's generated).

b) Likewise, this
              
   prefetch => 'controls',

   works and prefetches the controls.

c) This:

   prefetch => ['nodes', 'controls'],

   says:

    DBIx::Class::ResultSet::find(): Prefetch not supported with accessor 'multi' at scripts/foo.pl line 108

   which comes from the exception at the bottom of
   DBIx::Class::ResultSet::inflate_column.

d) This

   prefetch -> {nodes => node_attrs}

   seems to work to and pulls in the the node_attrs (saving me many
   round trips to the db!).

e) This

   prefetch => {nodes => nodes_attrs,
                controls => controls_attrs},

   generates bogus sql on which Pg barfs.  It ends up left joining
   nodes, node_attrs, controls, and control_attrs twice.

   Assuming that this is supposed to work, then there's a buglet that
   can be ameliorated by changing line 138 in ResultSet.pm from 

     push(@{$attrs->{from}}, $source->resolve_join($p, $attrs->{alias}))

   to

     push(@{$attrs->{from}}, $source->resolve_join({$key => $p->{key}},
                                                    $attrs->{alias}))

   since it otherwise passes the entire hash in both times.

   With that "fix" in place, this prefetch generates the same
   exception described in c) above.

I'm trying to figure out what's causing the exception in inflate_row.

I'd appreciate any commentary about what the syntax of the prefetch
attribute should be to populate an rn, which has_many nodes (which
has_many node_attrs) and which has_many controls (which has_many
control_attrs)?

Thanks,

g.