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

[Peter Rabbitson]

On Wed, Feb 20, 2013 at 03:37:58PM +0100, Wolfgang Kinkeldei wrote:
> Hi Peter,
> 
> Am 20.02.2013 um 15:04 schrieb 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.
> 
> well, at least under 0.08208 I get a result back that looks like:
> 
> $VAR1 = [
>           {
>             'concept' => {
>                            'concept_id' => 811,
>                            'foldername' => '...'
>                          },
>             'foldername' => '...',
>             'subelement_id' => 40779
>           },
>           ...
> 
> the structure of the hashref returned does not match the belongs-to hierarchy of the tables involved which was intended at the time the query was written. If my way of (mis-)using the "columns" specification was not as desired, it is not a bug, but a (maybe unplanned) "feature" of the previous version. In this case some words of warning inside the documentation should be enough.
> 

Right, at this point we have an "undefined situation turned into an 
unplanned feature", therefore 0.08242 will downgrade the exception to a 
single-warning-per-process. This seems like a sane middle ground for 
"you gave me an 'as' that worked by accident before - fix it at your 
convenience".

I'll contact you for preliminary testing when the patch is ready (couple 
days, ETIME). Do *not* change your code - it will continue to work.

Cheers