Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
On Sun, Feb 24, 2013 at 12:56 AM, Peter Rabbitson wrote: > > '+columns' => ['external_authentications.md5key'], > > > > to this fixed it: > > > > '+select' => ['external_authentications.md5key'], > > '+as' => ['md5key'], > > > > See the "do not change your code" line at the end of: > http://lists.scsys.co.uk/pipermail/dbix-class/2013-February/09.html > > I saw that. I'll test again when the new release candidate is ready. -- Bill Moseley mose...@hank.org ___ 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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
On Sat, Feb 23, 2013 at 10:14:56PM -0800, Bill Moseley wrote: > On Wed, Feb 20, 2013 at 5:44 AM, Wolfgang Kinkeldei > wrote: > > > > > The error message reported reads: > > > > "DBIx::Class::ResultSet::all(): Inflation into non-existent relationship > > 'concept' of 'Subelement' requested, check the inflation specification > > (columns/as) ending in '...concept.concept_id' " > > > > > Just FYI, > > $VERSION = '0.08241'; > > I'm seeing the same error: > > DBIx::Class::ResultSet::first(): Inflation into non-existent relationship > 'external_authentications' of 'Assignment' requested, check the inflation > specification (columns/as) ending in '...external_authentications.md5key' > > > In my case changing from this: > > '+columns' => ['external_authentications.md5key'], > > to this fixed it: > > '+select' => ['external_authentications.md5key'], > '+as' => ['md5key'], > See the "do not change your code" line at the end of: http://lists.scsys.co.uk/pipermail/dbix-class/2013-February/09.html ___ 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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
On Wed, Feb 20, 2013 at 5:44 AM, Wolfgang Kinkeldei wrote: > > The error message reported reads: > > "DBIx::Class::ResultSet::all(): Inflation into non-existent relationship > 'concept' of 'Subelement' requested, check the inflation specification > (columns/as) ending in '...concept.concept_id' " > > Just FYI, $VERSION = '0.08241'; I'm seeing the same error: DBIx::Class::ResultSet::first(): Inflation into non-existent relationship 'external_authentications' of 'Assignment' requested, check the inflation specification (columns/as) ending in '...external_authentications.md5key' In my case changing from this: '+columns' => ['external_authentications.md5key'], to this fixed it: '+select' => ['external_authentications.md5key'], '+as' => ['md5key'], -- Bill Moseley mose...@hank.org ___ 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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
On Fri, Feb 22, 2013 at 11:05:53PM +1100, Peter Rabbitson wrote: > . . . the map is strictly mirroring the > current relationship graph of your schema. To clarify this bit as it is in contradiction with http://lists.scsys.co.uk/pipermail/dbix-class/2013-February/09.html The old behavior will be reenabled for HashRefInflator only to allow people to not have to re-audit tons of code where HRI used to work just fine. The search() call in that example never worked without HRI and will continue to not work in the future, just the exception text will become clearer. ___ 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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
On Fri, Feb 22, 2013 at 11:45:54AM +, Will Crawford wrote:
> On 22 February 2013 11:36, Peter Rabbitson wrote:
>
>
> > At first glance yes. The problem here is that you are incorrectly
> > assuming that given 'concept.concept_id' one can simply infer we are
> > talking about the 'concept' from join => { element => 'concept' }.
> >
> > However the moment *another* 'concept' appears, possibly due to chaining
> > somewhere deep in your app - what do you do? Here is a real test case: [1]
>
>
> That problem already exists when referring to the alias of a
> joined/prefetched table in the 'select' list or search specification,
> though - this wouldn't introduce any *new* ambiguity at all, surely?
Incorrect - the 'select' argument takes proper storage-side aliases to
pass to the SQL generator (currently SQL::Abstract). So in the example
case you can specify artist.foo or artist_2.foo and everything will
remain correct. Furthermore frew is working on functionality to allow
specification of custom alias-names for each node in a thejoin/prefetch
structure. So that is currently unambiguous but obtuse, and in the
future will just get easier.
The 'as' specification however is in essence an "inflation_map" (we may
end up renaming this attribute - it is too confusing as it stands (while
maintaining backcompat obviously)). In the inflation map there is no
place for alias interpretation - the map is strictly mirroring the
current relationship graph of your schema. So again - heuristics on the
contents of inlation_map/as is *not* something that the core of DBIC can
provide as it falls squarely in the 80/20 good-enough realm.
And to reiterate - a ResultSet role/component implementing such
"guessing" is very easy to write and CPANize.
___
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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
On 22 February 2013 11:36, Peter Rabbitson wrote:
> At first glance yes. The problem here is that you are incorrectly
> assuming that given 'concept.concept_id' one can simply infer we are
> talking about the 'concept' from join => { element => 'concept' }.
>
> However the moment *another* 'concept' appears, possibly due to chaining
> somewhere deep in your app - what do you do? Here is a real test case: [1]
That problem already exists when referring to the alias of a
joined/prefetched table in the 'select' list or search specification,
though - this wouldn't introduce any *new* ambiguity at all, surely?
___
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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
On Fri, Feb 22, 2013 at 11:23:50AM +, Will Crawford wrote:
> It would probably be more intuitive to return something like:
>
> {
> element => {
> concept => { concept_id => nnn, foldername => 'xxx' },
> ...
> },
> ...
> }
>
> ?
At first glance yes. The problem here is that you are incorrectly
assuming that given 'concept.concept_id' one can simply infer we are
talking about the 'concept' from join => { element => 'concept' }.
However the moment *another* 'concept' appears, possibly due to chaining
somewhere deep in your app - what do you do? Here is a real test case: [1]
Bottom line - heuristics at this level is undesireable, however a
sugar-providing ResultSet role to pre-munge the search attributes living
outside of DBIx::Class is free to try this.
[1]
http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=dbsrgits/DBIx-Class.git;a=blob;f=t/prefetch/diamond.t#l23
___
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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
It would probably be more intuitive to return something like:
{
element => {
concept => { concept_id => nnn, foldername => 'xxx' },
...
},
...
}
?
I've a couple of similar queries that I wrote before I started using HRI
much, though I had to use +select/+as then get_column(...) in the template
to get at the values. The first one's a lot more frequently used, though
neither that heavily that it's an issue yet.
$c->stash(
sets => [
$c->stash->{set_rs}->search(
{
@filter,
}, {
join => { zone => 'zone_type' },
'+select' => [ 'zone.title', 'zone_type.name' ],
'+as' => [ 'zone_title', 'zone_type' ],
order_by => $order_by
}
)->all
],
template => 'set/index.tt'
);
$c->stash(
collections => [
$c->stash->{rs}->search(
undef, {
'+select' => [ qw/main_media.spl_number/, { array_agg
=> 'contributor.spl_code', -as => 'contributor_codes' } ],
'+as' => [ qw/main_media_number contributor_codes/ ],
join => [ { collection_contributors => 'contributor' },
'main_media' ],
distinct => 1,
#group_by => [ qw/me.id me.title me.display me.is_new
me.is_featured me.media_type main_media.spl_number/ ],
order_by => $order_by,
}
)->all
],
template => 'collection/index.tt'
);
On 20 February 2013 14:04, Peter Rabbitson wrote:
> 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 => [4 .. 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
>
___
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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
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 => [4 .. 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
___
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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
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 => [4 .. 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
___
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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
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 => [4 .. 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
Re: [Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
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 => [4 .. 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.
The error message reported reads:
"DBIx::Class::ResultSet::all(): Inflation into non-existent relationship
'concept' of 'Subelement' requested, check the inflation specification
(columns/as) ending in '...concept.concept_id' "
Am 20.02.2013 um 12:31 schrieb Peter Rabbitson:
> Greetings
>
> Another release of the experimental constructor rewrite just hit CPAN.
> Please grab and test 0.08241-TRIAL from our nearest mirror [1]. You
> can install the release in question by simply executing:
>
> cpan R/RI/RIBASUSHI/DBIx-Class-0.08241-TRIAL.tar.gz
>
> or
>
> cpanm
> http://cpan.metacpan.org/authors/id/R/RI/RIBASUSHI/DBIx-Class-0.08241-TRIAL.tar.gz
>
> If the previous experimental release 0.08240 worked for you without
> any glitches - the same should be true for 0.08241. If you have not yet
> tested - PLEASE DO SO. If the release team does not hear anything within
> a couple of weeks this will become the official 0.08250, and you will get
> little sympathy if it ends up breaking your production afterwards ;)
>
> A minimal amount of changes, mostly dealing with providing even more
> compatibility with existing codebases. The notable change as described
> in the commit message of 52864fbd [2]
>
>. . . we no longer take an educated guess when to prune.
>Instead we mark each null-branch by simply blessing its containing
>arrayref. This allows us to keep the arguments to inflate_result 100%
>backwards compatible, while at the same time allowing "enlightened"
>inflate_result implementations to skip over the dead branches with
>minimal effort.
>
>Both ::Row::inflate_result and ::HRI::inflate_result were adjusted to
>react correctly to these marks. As a result the HRI folder gained
>another 5% speedup (unless sidestepped by the direct-to-HRI code, which
>is naturally much much more efficient).
>
> Cheers and thanks for testing!
>
> [1] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.08241-TRIAL
> [2] https://github.com/dbsrgits/dbix-class/commit/52864fbd
>
>
> ___
> 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
Grüße,
Wolfgang Kinkeldei
--
' /\_/\ ' .print[split??,"".(($/=q|Cms)+-03467:;<=|)=~tr!C-z -B! -z!)x
'( o.o )' .$/]->[hex]foreach split qr<>,qq+1ecd039ad65b025b8063475b+||
' > ^ < ' .q
___
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
[Dbix-class] [ANNOUNCE] A much faster DBIx::Class public trial round two - v0.08241
Greetings Another release of the experimental constructor rewrite just hit CPAN. Please grab and test 0.08241-TRIAL from our nearest mirror [1]. You can install the release in question by simply executing: cpan R/RI/RIBASUSHI/DBIx-Class-0.08241-TRIAL.tar.gz or cpanm http://cpan.metacpan.org/authors/id/R/RI/RIBASUSHI/DBIx-Class-0.08241-TRIAL.tar.gz If the previous experimental release 0.08240 worked for you without any glitches - the same should be true for 0.08241. If you have not yet tested - PLEASE DO SO. If the release team does not hear anything within a couple of weeks this will become the official 0.08250, and you will get little sympathy if it ends up breaking your production afterwards ;) A minimal amount of changes, mostly dealing with providing even more compatibility with existing codebases. The notable change as described in the commit message of 52864fbd [2] . . . we no longer take an educated guess when to prune. Instead we mark each null-branch by simply blessing its containing arrayref. This allows us to keep the arguments to inflate_result 100% backwards compatible, while at the same time allowing "enlightened" inflate_result implementations to skip over the dead branches with minimal effort. Both ::Row::inflate_result and ::HRI::inflate_result were adjusted to react correctly to these marks. As a result the HRI folder gained another 5% speedup (unless sidestepped by the direct-to-HRI code, which is naturally much much more efficient). Cheers and thanks for testing! [1] https://metacpan.org/release/RIBASUSHI/DBIx-Class-0.08241-TRIAL [2] https://github.com/dbsrgits/dbix-class/commit/52864fbd ___ 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
