[Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial
round two - v0.08241
Peter Rabbitson
rabbit+dbic at rabbit.us
Thu Feb 21 21:14:15 GMT 2013
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
More information about the DBIx-Class
mailing list