Re: with tied hash, 'each' gives key that doesn't 'exists'

Since you're not using the value, have you considered using keys instead of each? Maybe there's a bug in the DB_File implementation of each that is not in the keys implementation.

Also, have you considered using Data::Dumper or YAML to dump the hash to text and peruse it in your favorite editor? Sometimes patterns emerge just from getting a look at the data.

--marmot

Comment on Re: with tied hash, 'each' gives key that doesn't 'exists' Select or Download Code

Replies are listed 'Best First'.
Re^2: with tied hash, 'each' gives key that doesn't 'exists' by locked_user sundialsvc4 (Abbot) on Sep 16, 2010 at 17:08 UTC
FYI, `keys` would be very inappropriate in this case, because it would read the file twice ... build a complete list of the record keys in RAM (virtual memory) ... then retrieve the records by those keys. Most of the time you would run out of RAM. But even if you didn’t, you’d be doing a rather massively too-much amount of unnecessary work. `each`, on the other hand, simply walks through the file. There is no memory-footprint to speak of. Furthermore, it always does so in ascending order by key. Very often, that is exactly what you want. (What bearing if any this may have on this issue, I don’t know.)
Re^3: with tied hash, 'each' gives key that doesn't 'exists' by cmac (Monk) on Sep 18, 2010 at 06:18 UTC
It is not generally true that `each` returns keys (or key/value pairs) in ascending order by key. It is true for some base classes that one can tie a hash to, but not for `DB_File` which is what the OP is asking about. See the description of `each` in Programing Perl 3rd Edition p. 703.	[reply] [d/l] [select]
Re^2: with tied hash, 'each' gives key that doesn't 'exists' by hbm (Hermit) on Sep 16, 2010 at 16:49 UTC
I run out of memory with `keys`, hence `each`. I'll consider your other suggestions, but first I'm testing the latest DB_File. Thanks!	[reply] [d/l] [select]