in reply to Recursive hash assignment
The syntax in the first sample causes a full copy of the hash to be created from scratch; the other way simply stores a reference to the already built hash, which is much faster. Since a new hash is created by my on each loop iteration, taking a reference to it is okay.
You can further simplify this by reading perldoc -f delete and finding out that the function returns the value of the deleted element (so long as it's not a tied hash anyway). This means
can be contracted to $tableData{$hashkey}{delete $tblData{$key2}} = \%tblData;my $hashkey2 = $tblData{$key2}; delete $tblData{$key2}; $tableData{$hashkey}{$hashkey2} = \%tblData;
Now on to the juicy stuff. You can see that adding another level of depth to the hash assignment code always follows the same scheme, right? Well, it's just a matter of teaching Perl how to do that job for us. What we do is use eval to build a closure.
my @key = grep defined, $key, $key2, $key3; my %tableData; my $store_row = eval join("", q( sub { my $row = shift; $tableData), map("{delete \$row->{'$_'}}", @key), q( = $row; })); while (my @data = $dbh -> dbnextrow) { s/^\s|\s$//g for @data; my %tblData; @tblData{@columnnames} = @data; $store_row(\%tblData); }
Turns out to be rather short and painless. (Note I haven't tested this; I don't see any mistakes though.) This will work for any depth you want; just add keys to the @key array and off you go. I'm fairly confident that performance will be excellent. It would be best if you can arrange your keys to arrive in a @key array right away rather than in a loose collection of scalars. Note that the closure built takes a hashref as parameter.
Pay attention to the backslash-escaped sigil in "{delete \$row->{$_}}"; while the $_ is not protected. That means the keynames get interpolated at "compile time", as the closure's code is built.
Update 2002-09-09: "{delete \$row->{$_}}" will malfunction if the keyname has any whitespace characters. Added single quotes.
Makeshifts last the longest.
|
|---|