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

[Wolfgang Kinkeldei]

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.

> 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
> 
> 
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk


Best,

Wolfgang Kinkeldei

-- 

' /\_/\ ' .print[split??,"".(($/=q|Cms)+-03467:;<=|)=~tr!C-z -B! -z!)x
'( o.o )' .$/]->[hex]foreach split qr<>,qq+1ecd039ad65b025b8063475b+||
' > ^ < ' .q<!-- Wolfgang Kinkeldei - wolfgang at kinkeldei dot de -->