I even went so far as to implement FIRSTKEY in DBI.xs, which did make my error go away, but made Devel::GC::Helper get stuck in an infinite loop.
If your FIRSTKEY didn't return an empty list (or undef?) then you might cause an infinite loop.
It'd be interesting to figure out what causes this failure of not finding DBI::FIRSTKEY. You seem in a good position to do that, already having a test case and jumping into the C debugger with it. :)
| [reply] |
| [reply] |
I explained why the missing DBI::FIRSTKEY() incorrectly gives a confusing error message about not finding an auto/DBI/FIRSTKEY.al file. Last I read that thread there were no real explanation about why the DBI::FIRSTKEY() method isn't found (other than my guess that "it doesn't exist") or why Devel::GC::Helper tries to look for it.
I revisited my testing and found that there isn't a DBI::FIRSTKEY() but things like a DBI::db::FIRSTKEY(). So the question becomes why is Devel::GC::Helper finding a tied hash blessed into DBI (not DBI::db or some other class) or acting like it is.
| [reply] |