Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Is this DBM::Deep behavior, or something with tie/bless?

by romandas (Pilgrim)
on Jan 29, 2008 at 22:52 UTC ( #665030=perlquestion: print w/ replies, xml ) Need Help??
romandas has asked for the wisdom of the Perl Monks concerning the following question:

Hello all, I am a relatively inexperienced Perl programmer (still working my way through Intermediate Perl).
While working on using DBM::Deep, I noticed some behavior I cannot explain.
I am using DBM::Deep 0.983 because there are no later versions available from ActiveState. Here is my code:
#!/perl/bin/perl use strict; use warnings; use DBM::Deep; use Data::Dumper; unlink("test.db"); my $database = DBM::Deep->new( file => "test.db", locking => 1, autoflush => 1 ); # Test array that contains a hash reference as an element my @array = ("Mac Address", "PCNAME", 1, 1187000400, { 'bob' => 23, ' +alice' => 20 }); print("\@array\n", Dumper(\@array)); # Shows the contents of the ar +ray, with no blessed references and nothing tied to the DBM::Deep dat +abase $database->{141} = \@array; # Assigns the array reference as a valu +e of the DBM::Deep database hash print("\@array\n", Dumper(\@array)); # Now the original array's int +ernal hash is tied or blessed or something to the database my $temp = $database->{141}->export; # Export should return a refer +ence to an array in which the internal hash is not tied to the databa +se anymore print("\$temp\n", Dumper($temp)); # Dumper shows no tied or blessed + hash; seems like it worked. my @new_array = @{ $temp }; # Dereferencing the array reference to +reconstitute the array. print("\@new_array\n", Dumper(\@new_array)); # The new array's hash + reference is normal. @array = @{ $temp }; # Assigning the array reference to the origina +l array variable.. should work fine. print("\@array\n", Dumper(\@array)); # This prints a hash reference + that is still tied to the database. WTF? my @array = @{ $temp }; # Assigning the array reference to the orig +inal array variable but redeclaring it using my. print("\@array\n", Dumper(\@array)); # This works... Why is redecl +aring the variable important? Why doesn't the reassignment work?
My questions, as shown in the comments, are:
1) Why does the hash reference, which prints clearly on its own, show a connection to the database when dereferenced and stored in the original array?
2) Why does using a new array, or redeclaring the array using 'my' fix this? I assume the answer is the same for both new and 'my' but do not understand either way.

Note: Running this on my Linux machine instead of my Windows machine does not yield a fix using 'my' again, but instead gives a warning of '"my" variable @array masks earlier declaration in same scope at test_dbm.pl line 30'. Of course, my Linux machine has DBM::Deep 1.0007 installed.

Any enlightenment you can provide would be most appreciated.

Comment on Is this DBM::Deep behavior, or something with tie/bless?
Download Code
Re: Is this DBM::Deep behavior, or something with tie/bless? (normal)
by tye (Cardinal) on Jan 30, 2008 at 04:35 UTC

    Assigning to a tied array puts stuff in the database. It doesn't replace the array with an untied array. That is normal. The new array isn't tied so, of course, assigning to it doesn't cause a tie relationship to suddenly appear.

    - tye        

      Thanks for the help!

      So, if I use 'untie @array' prior to the reassignment, that should work, right? Does assigning undef do the same thing?

      On a not-strictly-Perl question, a friend who I had look at the same code said I was improperly reusing a variable by assigning a value back to it, but I'm not sure why he thought that was improper. Is there some part of 'programming best practice' that talks about variable reuse?
        Is there a reason you want to untie the array? Generally, you just care about the data being on the disk and don't much care beyond that.

        As for assigning the variable back to itself, it's generally frowned upon because it's usually a no-op. If it actually does something, then there's deep magic going on and, in general, deep magic is usually clever magic. Clever is the polite way of saying "stupid."


        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: Is this DBM::Deep behavior, or something with tie/bless?
by dragonchild (Archbishop) on Jan 31, 2008 at 05:14 UTC
    export() and import() in DBM::Deep 0.983 don't quite work. The test script above does work correctly in 1.007 and I'm working with a couple developers who are much more expert than I am on Win32 to get a 1.008 out ASAP. We think we have a workaround, but it's so deep in the guts that it just takes a little time to properly vet it.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://665030]
Approved by kyle
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (4)
As of 2014-09-02 02:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (18 votes), past polls