ralphie has asked for the wisdom of the Perl Monks concerning the following question:

hi all-
one of my scripts parses a very complex log produced by a piece of lab equipment. the most reliable format that i've been able to put together for the parsing operation involves stepping through the log until a line is reached that signals the beginning of a set of results, which triggers the extraction operation, parses the values, checks to see if they've been stored before, and inserts them into a postgresql database. i only extract one record on each pass through the file, which may seem inefficient but is exhaustive and helps to assure that i don't miss a record ... this output file has all sorts of stuff in it.

i'm getting long winded - here's the rub. the key that identifies a unique run is the concantenation of three values, id, date, and time (date and time are both ascii representations extracted from the file). as a result, the constructed key can look like "12502-23-0110:13:53". in previous incarnations of the script i had simply issued a select againt the parent table to determine whether the value had previously been stored, but after updating my system to 5.6.1 and the latest Pg driver on cpan i found that a memory leak had been engendered by this scenario. rather than messing around with earlier versions to see if i could fix that, i decided to write a smarter lookup, dumping the keys into a hash and checking for the existence of the key there.

so i did (grin), extracting the keys with

my @keys=$count_stmnt->fetchall_arrayref(); $vals=@keys[0];
and then checking for the existence of the key with (exists $vals{$key}). the appropriate values are getting in the $vals hash ... i use ptkdb so i can evaluate that and see the values there, as is the $key value. except the exists function always returns "". from what i've read i'm pretty much going by the book implementing the exists function, and $key as a key works perfectly fine for database access ... i've set up a little web page as a query tool and issue queries against a joined view defined in postgresql using the same key field to associate the tables, and that works w/o any glitches.

i've given some thought that the problem may be associated with the "-"'s and ":"'s in the hash keys, wondering whether they create problems with the way the exists function looks through the hash, although it's clearly possible that i've missed something in how i'm implementing it.

any input would be appreciated.

Replies are listed 'Best First'.
Re: hash key lookups failing
by princepawn (Parson) on Nov 11, 2001 at 01:06 UTC
    There are a large and radical number of incongruences between the things you are saying and what the posted code belies. You should read "Advanced Perl Programming" or type perldoc perlref or buy another good Perl book on references.

    Anyway this code you posted :

    my @keys=$count_stmnt->fetchall_arrayref(); $vals=@keys[0];
    Does not fetch into a hashref. Why would you think a function called fetchall_arrayref returns a hashreference? I think you should also type perldoc DBI and read that as well.

    Here is how to get a hashref and use it

    my $hashref = $sth->fetchrow_hashref; $hashref->{key};
    But like I said, you appear to have a large number of basic and crucial misunderstandings. Also buy the book "Programming the Perl DBI" from O'Reilly.

    I hope this post sounds direct but not rude.

Re: hash key lookups failing
by Zaxo (Archbishop) on Nov 11, 2001 at 01:10 UTC

    I'm not sure I follow all that, but you are misusing fetchall_arrayref(). It's an AoAref. Does this do what you want?

    my $keys = $count_stmnt->fetchall_arrayref(); my @vals = map {$_->[0]} @{$keys};
    I'm sure thare's a slicker way to deref the field you want.

    After Compline,
    Zaxo

      zaxo-
      thanks for your reply. i know there's probably a better way to get the hash than the one i'm currently using, but the hash is there and populated appropriately. i actually used the arrayref method because of something i read here, though in all honesty i can't remember the full thought process that went behind it.

      all this is beside the point. appropriate values are in the hash and in the scalar. the stuff is at work so i can't paste it in here. i'll concede that it is not inconceivable that the way i'm retrieving the hash might be affecting it's representation, thus affecting the ability of the exists function to find a value, but i think it's at least as likely that the dashes and colons in my constructed key are the source of the problem.

        exists has no "limitations". If it's in the hash, it can find it. I would rather guess you're passing it something you think looks right, which isn't; so exists() goes looking either for something other than you mean to tell it to, or in some place you didn't mean to tell it to - or both.

        You quite certainly don't want to write $vals=@keys[0];, it is $vals=$keys[0]; since the value you're getting back is a single scalar. $scalar = @array[0]; only works due to a mere coincidence in the language setup. Judging from so little evidence I can't be sure of course, but I suspect you come from a tranditional language and haven't yet fully understood the notion of scalar/list context; if so, you should realy work on that since otherwise you're likely to make a lot of mistakes with what will look like positively bizarre effects.

        But maybe we can clear up both points if you can paste some more of your code :)
Re: hash key lookups failing - resolution
by ralphie (Friar) on Nov 14, 2001 at 02:13 UTC
    for anyone who gets this far down in the thread, maybe an e-archeologist at some point in the future, chronicling the bizaare ways of a certain e-tribe

    i've seen the error of my ways. my intent was to create a hash out of the values of the key column from one of my tables. a combination of weariness and the lateness of the day on friday prevented me from seeing the arrayref notation in the ptkdb window, contributing to my misunderstanding. i've constructed the hash by looping through the table and assigning the key to the hash ... all is now hunky-dory. i intend to further enhance my understanding at some point by playing around with other ways to do this, but i'm going to wait for a time at which i perceive that i have a karmic debt to mitigate.