Re^3: DBM::Deep Problem

my %h = %{$db->{hash}}; #get hash from db
$h{key}->[0]=99;        #alter value
$db->{hash} = \%h;      #put hash back in

print $db->{hash}->{key}->[0]; #99
[download]

Yes. This is ugly. This weird sysntax is caused by the tie-mechanism, which cannot handle deep structures.
If you do $db->{hash}->{key}->[0] = 99 you change the data, but the change is not reported to the underlying (tied) object. see perltie for more.

holli, /regexed monk/

Comment on Re^3: DBM::Deep Problem Select or Download Code

Replies are listed 'Best First'.
Re^4: DBM::Deep Problem by merlyn (Sage) on May 18, 2005 at 12:27 UTC
That's not quite the problem. You're mixing up the MLDBM strategy (which ties only the top level hash) with the DBM::Deep strategy, which can return tied objects for every level, provided you don't tickle the autovivify bug. If you understand what's happening, you'll see that what you just did is unneeded. The autovivify bug is that STORE is not called on tied hash %H when `$H{foo}->{bar} = 3` autovivs a hashref in `foo`. This is a legitimately broken problem. The workaround is doing it step by step: `$H{foo} \|\|= {}; # manual viv to work around tie-autoviv bug $H{foo}{bar} = 3; # now this gets stored right` [download] And this is not the problem in MLDBM. MLDBM is simple-minded, attempting to tie only the top-level hash. -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply] [d/l] [select]
Re^4: DBM::Deep Problem by travisbickle34 (Beadle) on May 18, 2005 at 08:58 UTC
Excellent! I'll have to take some time to understand the inner workings of what's happening, but this will get my code working in the meantime. Thanks again! tb34	[reply]