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
_______________________________________________
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
