in reply to Re: DBM::Deep Problem
in thread DBM::Deep Problem

That seems to work - it definitely prints the value first time at least. Thanks :-)

One other question though (I'm pretty new to the OO syntax) - how would I cahnge the second element (index value 1) in the same anonymous array?

Replies are listed 'Best First'.
Re^3: DBM::Deep Problem
by holli (Abbot) on May 18, 2005 at 08:53 UTC
    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
    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/
      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

      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.

      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