Bug #57070 for DBM-Deep: Re-assignment of nested structures fails

Thu Apr 29 22:06:50 2010 mutant.nz [...] gmail.com - Ticket created

Subject:

Re-assignment of nested structures fails

If I copy a deep structure, then reassign it back to the db, I get: Can't call method "offset" on an undefined value at /usr/local/share/perl/5.10.0/DBM/Deep/Sector/File/BucketList.pm line 22 Minimal example: my $db = DBM::Deep->new( file => '/tmp/test', ); my $new = {bar => 1, baz => 2}; $db->{foo} = [$new]; my @new = @{$db->{foo}}; $db->{foo} = \@new; # Dies Looking at the dumped data, it looks like the deep copy is returning blessed objects rather than plain old hashes, which could be where the problem lies. This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi Linux samc-pc 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC 2010 x86_64 GNU/Linux CPAN_FILE S/SP/SPROUT/DBM-Deep-1.0022.tar.gz

Sun May 02 16:34:23 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Thu Apr 29 22:06:50 2010, Mutant wrote: Show quoted text

> If I copy a deep structure, then reassign it back to the db, I get: > > Can't call method "offset" on an undefined value at > /usr/local/share/perl/5.10.0/DBM/Deep/Sector/File/BucketList.pm line 22 > > Minimal example: > > my $db = DBM::Deep->new( > file => '/tmp/test', > ); > my $new = {bar => 1, baz => 2}; > $db->{foo} = [$new]; > > my @new = @{$db->{foo}}; > $db->{foo} = \@new; # Dies > > Looking at the dumped data, it looks like the deep copy is returning > blessed objects rather than plain old hashes, which could be where the > problem lies.

If you change the Show quoted text

> my @new = @{$db->{foo}};

to Show quoted text

> my @new = @{$db->{foo}->export};

the problem will go away. DBM::Deep returns blessed objects by design, so that each successive level of data still accesses the database. This problem you have encountered is a necessary side-effect of that design. I don’t think there is any way to solve it, apart from using ->export. Show quoted text

> > This is perl, v5.10.0 built for x86_64-linux-gnu-thread-multi > Linux samc-pc 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 04:38:19 UTC > 2010 x86_64 GNU/Linux > CPAN_FILE S/SP/SPROUT/DBM-Deep-1.0022.tar.gz

Sun May 02 16:34:25 2010 The RT System itself - Status changed from 'new' to 'open'

Sun May 02 16:34:25 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Status changed from 'open' to 'resolved'

Sun May 02 16:47:03 2010 mutant.nz [...] gmail.com - Correspondence added

From:

mutant.nz [...] gmail.com

Show quoted text

> the problem will go away. DBM::Deep returns blessed objects by design, > so that each > successive level of data still accesses the database. This problem you > have encountered is a > necessary side-effect of that design. I don’t think there is any way > to solve it, apart from > using ->export.

Hi, fair enough, but if that's the case, you may want to update the docs, as it says things like: "Because all DBM::Deep objects are tied to hashes or arrays, you can treat them as such." In fact, maybe it'd be a good idea to explain this in detail in the tie interface section, as it can be quite confusing (you'd usually expect a tie to work just like a variable). Thanks.

Sun May 02 16:47:04 2010 The RT System itself - Status changed from 'resolved' to 'open'

Sun May 02 20:59:29 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sun May 02 16:47:03 2010, Mutant wrote: Show quoted text

> > the problem will go away. DBM::Deep returns blessed objects by design, > > so that each > > successive level of data still accesses the database. This problem you > > have encountered is a > > necessary side-effect of that design. I don’t think there is any way > > to solve it, apart from > > using ->export.

> > Hi, fair enough, but if that's the case, you may want to update the > docs, as it says things like: > > "Because all DBM::Deep objects are tied to hashes or arrays, you can > treat them as such." > > In fact, maybe it'd be a good idea to explain this in detail in the tie > interface section, as it can be quite confusing (you'd usually expect a > tie to work just like a variable).

Just to clarify, the fact that the aggregates returned from the database are blessed is irrelevant. They are tied, too, which, even without the blessing, would cause the same problem. I will try to improve the documentation, and maybe even improve the error messages, if that can be done without a performance penalty.

Sun May 16 16:04:15 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sun May 02 20:59:29 2010, SPROUT wrote: Show quoted text

> On Sun May 02 16:47:03 2010, Mutant wrote:

> > > the problem will go away. DBM::Deep returns blessed objects by

> design,

> > > so that each > > > successive level of data still accesses the database. This problem

> you

> > > have encountered is a > > > necessary side-effect of that design. I don’t think there is any

> way

> > > to solve it, apart from > > > using ->export.

> > > > Hi, fair enough, but if that's the case, you may want to update the > > docs, as it says things like: > > > > "Because all DBM::Deep objects are tied to hashes or arrays, you can > > treat them as such." > > > > In fact, maybe it'd be a good idea to explain this in detail in the

> tie

> > interface section, as it can be quite confusing (you'd usually

> expect a

> > tie to work just like a variable).

> > Just to clarify, the fact that the aggregates returned from the > database are blessed is > irrelevant. They are tied, too, which, even without the blessing, > would cause the same > problem. > > I will try to improve the documentation, and maybe even improve the > error messages, if that > can be done without a performance penalty.

I’ve not forgotten about this. I think I’ve come up with a way for these types of reassignments to work reliably. It may take a week or two, though (or longer).

Mon May 17 21:52:24 2010 mutant.nz [...] gmail.com - Correspondence added

From:

mutant.nz [...] gmail.com

Show quoted text

> I’ve not forgotten about this. I think I’ve come up with a way for > these types of > reassignments to work reliably. It may take a week or two, though (or > longer).

That's good news. This problem hasn't prevented me from using DBM::Deep, though, as it was fairly easy to work around.

Sun May 30 17:31:14 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Mon May 17 21:52:24 2010, Mutant wrote: Show quoted text

> > I’ve not forgotten about this. I think I’ve come up with a way for > > these types of > > reassignments to work reliably. It may take a week or two, though (or > > longer).

> > That's good news. This problem hasn't prevented me from using DBM::Deep, > though, as it was fairly easy to work around.

I’ve just released 1.0024, which has the first half of the fix: Now DBM::Deep will provide helpful error messages. I still plan to add a mode that will allow external references to database locations to ‘hang on’ to the data.

Sun Jun 20 16:08:28 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sun May 30 17:31:14 2010, SPROUT wrote: Show quoted text

> On Mon May 17 21:52:24 2010, Mutant wrote:

> > > I’ve not forgotten about this. I think I’ve come up with a way for > > > these types of > > > reassignments to work reliably. It may take a week or two, though

> (or

> > > longer).

> > > > That's good news. This problem hasn't prevented me from using

> DBM::Deep,

> > though, as it was fairly easy to work around.

> > I’ve just released 1.0024, which has the first half of the fix: Now > DBM::Deep will provide helpful > error messages. > > I still plan to add a mode that will allow external references to > database locations to ‘hang on’ > to the data.

Though it’s not in a release yet, there is now an external_refs mode: http://github.com/robkinyon/dbm-deep/commit/dd3d3cb63 If you want to try it out, you can get a snapshot of the working copy by clicking the ‘Download Source’ button at the top right of this page: http://github.com/robkinyon/dbm-deep

Sun Jul 18 17:31:35 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Correspondence added

On Sun Jun 20 16:08:28 2010, SPROUT wrote: Show quoted text

> On Sun May 30 17:31:14 2010, SPROUT wrote:

> > On Mon May 17 21:52:24 2010, Mutant wrote:

> > > > I’ve not forgotten about this. I think I’ve come up with a way

> for

> > > > these types of > > > > reassignments to work reliably. It may take a week or two,

> though

> > (or

> > > > longer).

> > > > > > That's good news. This problem hasn't prevented me from using

> > DBM::Deep,

> > > though, as it was fairly easy to work around.

> > > > I’ve just released 1.0024, which has the first half of the fix: Now > > DBM::Deep will provide helpful > > error messages. > > > > I still plan to add a mode that will allow external references to > > database locations to ‘hang on’ > > to the data.

> > Though it’s not in a release yet, there is now an external_refs mode: > > http://github.com/robkinyon/dbm-deep/commit/dd3d3cb63 > > If you want to try it out, you can get a snapshot of the working copy > by clicking the > ‘Download Source’ button at the top right of this page: > > http://github.com/robkinyon/dbm-deep >

I’ve just released version 2.0000, which includes this.

Sun Jul 18 17:31:36 2010 $_ = 'spro^^*%*^6ut# [...] &$%*c>#!^!#&!pan.org'; y/a-z.@//cd; print - Status changed from 'open' to 'resolved'