in reply to (Package Data) RE: (3) You can't get there from here....
in thread References of Eternal Peril

That makes the variable name collision less likely, but what if you pick a package name someone else is using? (If your code ends up in a module somewhere and someone else uses it, there's a possibility.) Plus, it means your template variable references will require package name prefixes. (I suppose you could also put a package statement and the templating sections within a block.)

I doubt it's as efficient as just using the fetch hashref method, but I don't have numbers to back that up. You'll still have potential typos to deal with (in your template), and symbolic references (for little gain, in my opinion), and you'll have to write more documentation on what's going on (and hopefully why) for yourself and future potential maintainers.

I don't think this technique is going to save you anything over the method DBI already provides, in the long run.

  • Comment on RE: (Package Data) RE: (3) You can't get there from here....

Replies are listed 'Best First'.
RE: (2) (Package Data) RE: (3) You can't get there from here....
by mwp (Hermit) on Aug 12, 2000 at 00:28 UTC

    In all probability, you're right. I'm trying to design a hack for a hack for a hack (or something along those lines) and I'm being stubborn and insolent by proceeding along this thought line. :-)

    However, I should point out that the DBI author describes a 1:4 decrease in performance when switching from fetch (binded columns) to fetchrow_array. I'm not sure where fetchrow_hashref sits in relation to fetchrow_array, but I don't doubt it's as-bad or worse.

    On the other hand, he also says that this is due to the limitations of Perl and how it handles memory, and not because of DBI or the database engine. So it's doubtful that this method will gain anything over fetchrow_hashref, as you said. But maybe it's work checking out.

    I have no qualms about writing $a::name instead of $a->{name} if it's four (or even two) times faster. This also deserves to be compared to a standard bind_columns routine, and the fetchrow_arrayref ($a->[0]) method. There's very little doubt in my mind that bind_columns is fastest, followed by arrayref, hashref, then array. I'm just curious to see where this technique fits in, and if it can be adapted to increase A) readability in situations where fetchrow_arrayref is being used, and B) speed in situations where fethrow_hashref is being used.

    <goes to dust of the ol' test tubes>

    Alakaboo

[reply]
[d/l]
[select]
      The only other idea I have uses a list reference and a hash slice with bind_columns. I haven't tested this with DBI, but I did test it standalone. 
      #!/usr/bin/perl -w

use strict;

my %h;
my @cols = qw( one two three four );
@h{@cols} = ( 1 .. 4 );

assign( \( @h{ @cols } ) );
print "$_ => $h{$_}\n" foreach @cols;

sub assign {
    my $val = 0;
    foreach (@_) {
        $$_ = $val++;
    }
}

      [download]
      There. You name your variables only once (outside of the template section), bind them to columns for speed, and are able to access them via a hash lookup. No symbolic references, and the only ugly construct is making a list of references from a hash slice. That beats the map stuff in my book, and it looks like a spaceship. You can't go wrong there.
[reply]
[d/l]

In Section Seekers of Perl Wisdom