Skip Menu |

This queue is for tickets about the DBM-Deep CPAN distribution.

Report information
The Basics
Id: 29583
Status: resolved
Priority: 0/
Queue: DBM-Deep

People
Owner: RKINYON [...] cpan.org
Requestors: hanenkamp [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 1.0002
Fixed in: (no value)



Subject: shifting from an array with nested arrays causes an exception
It's possible that I've missed something in the docs that tells me how to work around or correct this issue, but I haven't found it. To recreate the issue: use DBM::Deep; $x=DBM::Deep->new("test.db"); push @{ $x->{a} }, [ rand(100), rand(100), rand(100) ] for 1 .. 3; $y=$x->{a}; $z = shift(@$y); print @$z' The code never completes because it dies when it tries to run shift(@$y), with this error: DBM::Deep: Cannot store something that is tied. I presume (without having dug through the code) that this is being caused because shift() is reassigning the array to $y, but since the sub-elements are arrays that have been blessed into DBM::Deep, it's tripping on this error condition. I've run into that problem a number of times while performing a few operations involving moving values around and such. In most cases previously, it's been easy enough to clean up the data by copying the data out into a clean array or hash and then storing a new reference to the clean data. However, that's not always easy.
As an additional side note, it would be nice if this DBM::Deep error croaked with the caller's line number. It's a PITA to find where the code is failing since it doesn't reply with any line number at all. On Sun Sep 23 17:19:36 2007, HANENKAMP wrote: Show quoted text
> It's possible that I've missed something in the docs that tells me how > to work around or correct this issue, but I haven't found it. > > To recreate the issue: > > use DBM::Deep; > $x=DBM::Deep->new("test.db"); > push @{ $x->{a} }, [ rand(100), rand(100), rand(100) ] for 1 .. 3; > $y=$x->{a}; > $z = shift(@$y); > print @$z' > > The code never completes because it dies when it tries to run > shift(@$y), with this error: > > DBM::Deep: Cannot store something that is tied. > > I presume (without having dug through the code) that this is being > caused because shift() is reassigning the array to $y, but since the > sub-elements are arrays that have been blessed into DBM::Deep, it's > tripping on this error condition. > > I've run into that problem a number of times while performing a few > operations involving moving values around and such. In most cases > previously, it's been easy enough to clean up the data by copying the > data out into a clean array or hash and then storing a new reference to > the clean data. However, that's not always easy.
Okay, found export(), which helps with the cleaning, so that's the work-around.
On Sun Sep 23 17:19:36 2007, HANENKAMP wrote: Show quoted text
> It's possible that I've missed something in the docs that tells me how > to work around or correct this issue, but I haven't found it. > > To recreate the issue: > > use DBM::Deep; > $x=DBM::Deep->new("test.db"); > push @{ $x->{a} }, [ rand(100), rand(100), rand(100) ] for 1 .. 3; > $y=$x->{a}; > $z = shift(@$y); > print @$z' > > The code never completes because it dies when it tries to run > shift(@$y), with this error: > > DBM::Deep: Cannot store something that is tied. > > I presume (without having dug through the code) that this is being > caused because shift() is reassigning the array to $y, but since the > sub-elements are arrays that have been blessed into DBM::Deep, it's > tripping on this error condition. > > I've run into that problem a number of times while performing a few > operations involving moving values around and such. In most cases > previously, it's been easy enough to clean up the data by copying the > data out into a clean array or hash and then storing a new reference to > the clean data. However, that's not always easy.
Ok - that's a bug that I thought I'd fixed in the 1.0002 release. But, my tests weren't strong enough. It'll be fixed in 1.0003. Sorry bout that. Rob
This is fixed in 1.0003.