Re^5: A problem with eval via DB_File->filter_fetch

Oh, it most certainly is not a 1-1 replacement by any means and it is slower by a decent amount (though still fast enough for most purposes). But, if you need a DBM that can handle (almost) every bit of Perl craziness you can throw at it . . . DB_File isn't it.

The Perfect is the Enemy of the Good.

Comment on Re^5: A problem with eval via DB_File->filter_fetch_value() and AUTOLOAD

Replies are listed 'Best First'.
Re^6: A problem with eval via DB_File->filter_fetch_value() and AUTOLOAD by dgorski (Initiate) on Apr 26, 2005 at 21:06 UTC
I've read the doco on DBM::Deep. It won't help me. I like the flat file create by DB_File with $DB_RECNO. In fact, I'm sort of hooked on it. What I was originally asking was: "can someone tell me why this is". So far all I've gotten are recommendations for other approaches. If I have a reference that is blessed into a class, why wouldn't the AUTOLOAD method of that class work? That's the real problem that I'm looking for an answer to. - Darrin	[reply]
Re^7: A problem with eval via DB_File->filter_fetch_value() and AUTOLOAD by dragonchild (Archbishop) on Apr 27, 2005 at 00:35 UTC
Best I can guess is a bug in the implementation of DB_File. I source-dove and got lost in the XS. Here's the thing - DB_File is really a tied hash. It pretends to be a tied array, if you want to, but I don't think it's really set up to be one. Create a .t that demonstrates the bug and what you think it should do, then submit it to http://rt.cpan.org The Perfect is the Enemy of the Good.	[reply]