in reply to Re^4: Devel::GC::Helper + DBI (easy)
in thread Devel::GC::Helper + DBI

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.

- tye        

Replies are listed 'Best First'.
Re^6: Devel::GC::Helper + DBI (search)
by quelquun (Initiate) on Oct 17, 2006 at 23:01 UTC
    Just today, after 2 years of DBI use w/o this problem, it pops up.

    Occurs during compile -- a 'use' of an application module is sufficient to set it off. 'use DBI' by itself does not trigger the problem.

    I haven't touched any of the modules associated w/ the perl installation, v. 5.8.7 from Activestate. I have been changing my application code, but the same sort of changes as usual.

    I have replaced the Perl install dir w/ a backup from a few days ago -- problem persists.

    SDE is Komodo, which has been getting into "Not Responding" mode more than usual.

    After adding the method to the top-level scope of DBI, the error message about not being able to locate FIRSTKEY.al goes away, BUT compile is kicked out from DBI, now with no message.

    AND: The current DBI module has the FIRSTKEY() on line 1335, below the top scope of DBI.pm; see below. The previous version of DBI, v 11.43 2004/02/01, has the same code. Adding the recommended sub DCL does not change things.



    ***********************************************************
    ***********************************************************

    <c>
    # $Id: DBI.pm 6755 2006-08-06 21:21:03Z timbo $
    # vim: ts=8:sw=4
    #
    # Copyright (c) 1994-2004 Tim Bunce Ireland
    ...
    #
    --------------------------------------------------------------------
    # === OPTIONAL MINIMAL BASE CLASSES FOR DBI SUBCLASSES ===

    # We only define default methods for harmless functions.
    # We don't, for example, define a DBD::_::st::prepare()
    { package # hide from PAUSE

    DBD::_::common;
    # ====== Common base class methods ======
    use strict;
    # methods common to all handle types:

    sub _not_impl {
    my ($h, $method) = @_;
    $h->trace_msg("Driver does not implement the $method
    method.\n"); return; # empty list / undef
    }
    # generic TIEHASH default methods:
    sub FIRSTKEY { }
    sub NEXTKEY { }
    sub EXISTS { defined($_[0]->FETCH($_1)) } # XXX undef?
    sub CLEAR { Carp::carp "Can't CLEAR $_[0] (DBI)" }
    ***********************************************************
    ***********************************************************
    <c/>
[reply]

      Note that the code you list defines DBD::_::common::FIRSTKEY, not DBI::FIRSTKEY: 

      { package # hide from PAUSE 

DBD::_::common;
# ...
sub FIRSTKEY { }

      [download]

      So the question remains: Why is DBI::FIRSTKEY being looked for? Most likely (which may not be that likely, given how weird this problem appears to be), is that you have a hash tied to something blessed into DBI but the tied hashes from DBI should be blessed into DBI::db or DBI::st or such.

      So use your debugger to trap the call to the DBI::FIRSTKEY you inserted and look at the call stack to figure out what code is triggering that call. Then you'll probably have to debug why the structure being used by that call got blessed into the wrong class.

      It might also be worth looking for known bugs in DBI and the version of DBD that you are using. Follow the "view/report bugs" link from DBI and similarly for your version of DBD.

      - tye        

[reply]
[d/l]

In Section Seekers of Perl Wisdom