FAQ
Anyone have some insight as to why I'm unable to successfully cache the dbh?


When calling the connect method I pass it a code reference like so:

my $dbh = get_dbh();
if ( ! $dbh ) {
$dbh = DBI->connect_cached ....
store_dbh( $dbh );
}
return $dbh;

This used to work with the older version of DBIx::Class.

Thanks,
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060809/03898cda/attachment.htm

Search Discussions

  • Matt S Trout at Aug 9, 2006 at 3:56 pm

    Tim Keefer wrote:
    Anyone have some insight as to why I'm unable to successfully cache the
    dbh?

    When calling the connect method I pass it a code reference like so:

    my $dbh = get_dbh();
    if ( ! $dbh ) {
    $dbh = DBI->connect_cached ....
    store_dbh( $dbh );
    }
    return $dbh;

    This used to work with the older version of DBIx::Class.
    Define "work". Define "doesn't work anymore".

    Post more code - we have no idea what your get_dbh and store_dbh routines are
    doing.

    Also, why do you need to do this rather than letting DBIC handle the $dbh for
    you? It's better at it than any code I've ever written to do it (I only wrote
    the very first version of the Storage code, Brandon and others have massively
    improved it since) ...
  • Brandon Black at Aug 9, 2006 at 3:56 pm

    On 8/9/06, Tim Keefer wrote:
    Anyone have some insight as to why I'm unable to successfully cache the
    dbh?

    When calling the connect method I pass it a code reference like so:

    my $dbh = get_dbh();
    if ( ! $dbh ) {
    $dbh = DBI->connect_cached ....
    store_dbh( $dbh );
    }
    return $dbh;

    This used to work with the older version of DBIx::Class.

    Thanks,
    Tim

    I'm not sure why you're usage broke. Could you be more explicit? What
    version did it work in? What version broke you? What's the exact subref
    you're passing to connect, and what else does it interact with (what does
    the code for get_dbh and store_dbh do, exactly)?

    Aside from all of that, what are you really trying to accomplish? The
    coderef form of input to connect_info was designed for certain very unusual
    usages that can't be handled any other (saner) way.

    -- Brandon
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060809/41020668/attachment.htm
  • Tim Keefer at Aug 9, 2006 at 4:12 pm
    unfortunately I didn't make note of the versions before I upgraded.

    We're trying to accomplish two things,
    1) pull database connection info out of our conf so the models can be shared
    between the web apps, scripts, etc.
    2) avoid extraneous connects to the database.

    Here's the exact code reference:

    sub db_Main {
    my $invocant = shift;
    my $class = ( ref $invocant ) ? ref $invocant : $invocant;

    my $dbh;

    my $helper = Gantry::Utils::DBConnHelper->get_subclass();

    $dbh = $helper->get_dbh();

    if ( not $dbh ) {
    my $conn_info = $helper->get_conn_info();

    my $db_options = $class->get_db_options();

    $db_options->{AutoCommit} = 0
    unless defined $db_options->{AutoCommit};

    $dbh = DBI->connect_cached(
    $conn_info->{ 'dbconn' },
    $conn_info->{ 'dbuser' },
    $conn_info->{ 'dbpass' },
    $db_options
    );
    $helper->set_dbh( $dbh );
    }

    return $dbh;

    } # end db_Main

    On 8/9/06, Brandon Black wrote:


    On 8/9/06, Tim Keefer wrote:

    Anyone have some insight as to why I'm unable to successfully cache the
    dbh?

    When calling the connect method I pass it a code reference like so:

    my $dbh = get_dbh();
    if ( ! $dbh ) {
    $dbh = DBI->connect_cached ....
    store_dbh( $dbh );
    }
    return $dbh;

    This used to work with the older version of DBIx::Class.

    Thanks,
    Tim

    I'm not sure why you're usage broke. Could you be more explicit? What
    version did it work in? What version broke you? What's the exact subref
    you're passing to connect, and what else does it interact with (what does
    the code for get_dbh and store_dbh do, exactly)?

    Aside from all of that, what are you really trying to accomplish? The
    coderef form of input to connect_info was designed for certain very unusual
    usages that can't be handled any other (saner) way.

    -- Brandon


    _______________________________________________
    List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
    Wiki: http://dbix-class.shadowcatsystems.co.uk/
    IRC: irc.perl.org#dbix-class
    SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
    Searchable Archive:
    http://www.mail-archive.com/dbix-class at lists.rawmode.org/
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060809/24657d9c/attachment-0001.htm
  • Brandon Black at Aug 9, 2006 at 4:29 pm

    On 8/9/06, Tim Keefer wrote:
    unfortunately I didn't make note of the versions before I upgraded.
    What exactly is broken? What error messages/behavior happen that you
    expected to be different?

    We're trying to accomplish two things,
    1) pull database connection info out of our conf so the models can be
    shared between the web apps, scripts, etc.
    2) avoid extraneous connects to the database.

    Here's the exact code reference:

    [.......]
    Well, you could handle the configuration side of your issue easily without a
    coderef in connect_info, so I can only assume you're doing all of this
    because you're trying to share a single $dbh with non-DBIC code in the same
    running interpreter? Have you considered just connecting a $schema object
    using your info the normal way, and "sharing" the $dbh via mechanisms like:

    sub my_code_that_does_not_use_dbic_but_gets_dbh_from_a_dbic_schema {
    my ($self, $schema, @other_stuff) = @_;
    my $dbh = $schema->storage->dbh;
    $dbh->do(...);
    return;
    }

    This would allow DBIC to manage the $dbh for you and still give access to
    other code. DBIC has hundreds of lines of code devoted specifically to
    managed $dbh's better than your subroutine can - you should let it do the
    work for you if possible.

    The only known issue at the moment for 0.07000 sharing $dbh with other code
    is that when your connected schema object goes out of scope, its going to
    forcefully disconnect the active $dbh connection that other code might be
    using. There's a fix for that in -current, I'll make sure it makes it into
    trunk for 0.07001 too.

    -- Brandon
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060809/20d734e7/attachment.htm
  • Jess Robinson at Aug 9, 2006 at 4:30 pm

    On Wed, 9 Aug 2006, Tim Keefer wrote:

    unfortunately I didn't make note of the versions before I upgraded.

    We're trying to accomplish two things,
    1) pull database connection info out of our conf so the models can be shared
    between the web apps, scripts, etc.
    2) avoid extraneous connects to the database.

    Here's the exact code reference:

    sub db_Main {
    my $invocant = shift;
    my $class = ( ref $invocant ) ? ref $invocant : $invocant;

    my $dbh;

    my $helper = Gantry::Utils::DBConnHelper->get_subclass();

    $dbh = $helper->get_dbh();

    if ( not $dbh ) {
    my $conn_info = $helper->get_conn_info();

    my $db_options = $class->get_db_options();

    $db_options->{AutoCommit} = 0
    unless defined $db_options->{AutoCommit};

    $dbh = DBI->connect_cached(
    $conn_info->{ 'dbconn' },
    $conn_info->{ 'dbuser' },
    $conn_info->{ 'dbpass' },
    $db_options
    ) ;
    $helper->set_dbh( $dbh );
    }

    return $dbh;

    } # end db_Main
    I don't see where DBIx::Class is involved there at all?

    Jess
  • Matt S Trout at Aug 9, 2006 at 5:05 pm

    Tim Keefer wrote:
    unfortunately I didn't make note of the versions before I upgraded.

    We're trying to accomplish two things,
    1) pull database connection info out of our conf so the models can be
    shared between the web apps, scripts, etc.
    2) avoid extraneous connects to the database.

    Here's the exact code reference:
    Do

    sub db_Main {
    return Class->get_schema->storage->dbh;
    }

    instead. DBIC's $dbh handling is much, much better than what you just showed.
    Then just have the "Class" class make the connection from the config and stash
    it somewhere its get_schema method can get to.

    Nice to see Gantry users finally getting the message though; it's release as a
    new framework using CDBI::Sweet (which I wrote the join code for before giving
    up on CDBI and starting DBIx::Class) made me sad somewhat. Also, if there are
    any Gantry devs out there who'd been interested in collaboration with the
    Catalyst project we certainly would be; it seems to be a very similar
    framework bar the Sweet/codegen stuff and I imagine there's a lot of
    code-sharing that could be done.
  • Tim Keefer at Aug 9, 2006 at 7:10 pm

    On 8/9/06, Matt S Trout wrote:
    Tim Keefer wrote:
    unfortunately I didn't make note of the versions before I upgraded.

    We're trying to accomplish two things,
    1) pull database connection info out of our conf so the models can be
    shared between the web apps, scripts, etc.
    2) avoid extraneous connects to the database.

    Here's the exact code reference:
    Do

    sub db_Main {
    return Class->get_schema->storage->dbh;
    }

    instead. DBIC's $dbh handling is much, much better than what you just
    showed.
    Then just have the "Class" class make the connection from the config and
    stash
    it somewhere its get_schema method can get to.

    Nice to see Gantry users finally getting the message though; it's release
    as a
    new framework using CDBI::Sweet (which I wrote the join code for before
    giving
    up on CDBI and starting DBIx::Class) made me sad somewhat. Also, if there
    are
    any Gantry devs out there who'd been interested in collaboration with the
    Catalyst project we certainly would be; it seems to be a very similar
    framework bar the Sweet/codegen stuff and I imagine there's a lot of
    code-sharing that could be done.


    It appears that DBIC is even easier than I thought. Earlier, I found this in
    the docs that made me think caching wasn't being done DBIx::Class at the
    level we needed.

    "Note that DBIx::Class::Schema does not cache connections for you. If
    you use multiple connections, you need to do this manually."

    Yes, Gantry and Bigtop originally, and still supports Class::DBI models, but
    we have recently realized that it doesn't play well with the other non
    Class::DBI applications running in our mod_perl environment . We're now in
    the process of adding support for DBIx::Class models which is working fine
    running along side everything else.

    Thanks for your help,
    Tim
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.rawmode.org/pipermail/dbix-class/attachments/20060809/2b733561/attachment.htm
  • Matt S Trout at Aug 9, 2006 at 7:40 pm

    Tim Keefer wrote:
    It appears that DBIC is even easier than I thought. Earlier, I found
    this in the docs that made me think caching wasn't being done
    DBIx::Class at the level we needed.

    "Note that DBIx::Class::Schema does not cache connections for you. If
    you use multiple connections, you need to do this manually."
    Yes, as in "hold onto the $schema object for a connection you want to
    persist". It does specifically say "multiple connections" :)

    Generally assume that if CDBI has it, DBIC has the feature, and it probably
    works (for us at least) better and faster. The "exceptions" to this are
    automatically issuing random SELECTs when you call getters, the
    LiveObjectIndex and Class::DBI::Has::Been::Deleted, which production
    experience suggest are not features.
    Yes, Gantry and Bigtop originally, and still supports Class::DBI models,
    but we have recently realized that it doesn't play well with the other
    non Class::DBI applications running in our mod_perl environment . We're
    now in the process of adding support for DBIx::Class models which is
    working fine running along side everything else.
    Very cool. I'd love to see a DBIC version of Bigtop, it seemed like a rather
    neat concept.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupdbix-class @
categoriesperl, catalyst
postedAug 9, '06 at 3:31p
activeAug 9, '06 at 7:40p
posts9
users4
websitedbix-class.org
irc#dbix-class

People

Translate

site design / logo © 2021 Grokbase