You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I wrote this snippet to demonstrate either a problem with DBM::Deep, or maybe some misunderstanding by me of perl data structures:
#!/usr/bin/perl
use v5.36;
use strict;
use warnings;
use DBM::Deep;
my $deep = { table => [
{ key => 32, stuff => 'm' },
{ stuff => 'a' },
{ stuff => 'z' },
{ stuff => 'k' },
] };
say "table is $deep->{table}";
my $db = DBM::Deep->new("my.db");
$db->import($deep);
say "table is $db->{table}";
dumpmydb($db);
my(@newdata) = @{$db->{table}};
splice(@newdata,2,1);
@{$deep->{table}} = @newdata;
dumpmydb($deep); # call succeeds and dumps the structure
@{$db->{table}} = @newdata;
dumpmydb($db); # call fails to dump the structure
exit;
sub dumpmydb
{
say "----dump start--------";
my($ref) = @_;
foreach my $key (@{$ref->{table}})
{
say "key='$key'";
foreach my $subkey (keys %{$key})
{
my $value = $key->{$subkey};
say "subkey='$subkey'";
say "value='$value'";
}
}
say "----dump end--------";
}
I can assign @newdata to a substructure of $deep but not to the same (relative) substructure of $db. I've tried hard to keep this example as simple and small as possible. It does nothing useful except illustrate the problem I am encountering.
Again, I may have some mistaken idea about perl arrays, lists, hashes, references, or whatever else. However, your docs say (https://metacpan.org/pod/DBM::Deep#Arrays) that you can treat any DBM::Deep object like a normal Perl array reference, which I thought I am doing.
There is a caveat about large arrays (https://metacpan.org/pod/DBM::Deep#Large-Arrays), but I don't think my array is particularly large in any sense. But maybe my example suffers some of the same effects.
[Note: Actually, I have been using perl since 4.0.31 (?) or so. But I am always learning something new. I try not to be a know-it-all.]
The text was updated successfully, but these errors were encountered:
I refactored my example a bit to better clarify the innards:
use v5.36;
use strict;
use warnings;
use DBM::Deep;
use Data::Dumper;
my $deep = { table => [
{ key => 32, stuff => 'm' },
{ stuff => 'a' },
{ stuff => 'z' },
{ stuff => 'k' },
] };
say "deep";
say Dumper($deep);
my $db = DBM::Deep->new("my.db");
$db->import($deep);
say "imported db";
say Dumper($db);
my(@newdata) = @{$db->{table}};
say "newdata";
say Dumper(@newdata);
# change array so we can see a difference more clearly";
splice(@newdata,2,1);
say "newdata after splice";
say Dumper(@newdata);
# assignment succeeds and dump shows the contents from the assigned array
@{$deep->{table}} = @newdata;
say "deep after assignment";
say Dumper($deep);
# assignment fails and dump does not show the contents from assigned array
@{$db->{table}} = @newdata;
say "db after assignment";
say Dumper($db);
Running this code will show Data::Dumper output after each operation. I run perl v5.36 on devuan daedalus (bookworm). DBM::Deep modules and missing dependencies were built with cpanm.
I wrote this snippet to demonstrate either a problem with DBM::Deep, or maybe some misunderstanding by me of perl data structures:
I can assign
@newdata
to a substructure of$deep
but not to the same (relative) substructure of$db
. I've tried hard to keep this example as simple and small as possible. It does nothing useful except illustrate the problem I am encountering.Again, I may have some mistaken idea about perl arrays, lists, hashes, references, or whatever else. However, your docs say (https://metacpan.org/pod/DBM::Deep#Arrays) that you can treat any
DBM::Deep
object like a normal Perl array reference, which I thought I am doing.There is a caveat about large arrays (https://metacpan.org/pod/DBM::Deep#Large-Arrays), but I don't think my array is particularly large in any sense. But maybe my example suffers some of the same effects.
[Note: Actually, I have been using perl since 4.0.31 (?) or so. But I am always learning something new. I try not to be a know-it-all.]
The text was updated successfully, but these errors were encountered: