[Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241

[Peter Rabbitson]

On Wed, Feb 20, 2013 at 02:44:56PM +0100, Wolfgang Kinkeldei wrote:
> Hi,
> 
> I found one query in a current project that fails under 0.08241 but worked until 0.08208 (0.08240 left untested).
> 
> my join/columns combinations of do no longer work in combination with Hashref-inflation. A minimal query that triggers the message looks like:
> 
>     $schema->resultset('Subelement')
>            ->search(
>                 {
>                     'me.element_id' => { -in => [40000 .. 40010] },
>                 },
>                 {
>                     join => [
>                         { element => 'concept' },
>                     ],
>                     columns => [
>                         qw(me.subelement_id me.foldername concept.concept_id concept.foldername)
>                     ],
>                 })
>            ->as_hashref
>            ->all
> 
> there are 'belongs_to' relations existing: 'subelement' -> 'element' -> 'concept'. However, there is no relationship between 'subelement' and 'concept' as assumed by the Hashref-Inflator.

This is no what HRI assumes - this is what you told DBIC to do:

 columns => [ ... concept.concept_id ... ]

is equivalent to saying:

  select => [ ... concept.concept_id ... ]
  as => [ ... concept.concept_id ... ]

This 'as' specification reads like "Create a related object under the 
root object (subelement) using the relationship name and metadata of 
'concept' ". The reason you never saw this error before is that HRI 
didn't really care how it assembles the hash in a non-collapsing case. If 
you remove the ->as_hashref you will get a (much more cryptic) exception 
under 0.08208 as well with the above invocation.

So all in all I do not think this should be considered a bug - the args 
you supply to search() should be valid regardless of the result_class 
chosen later on. What do you think?

Cheers