Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: DBI perpare_cached and statment handle gone bad

by cbro (Pilgrim)
on Jul 08, 2003 at 20:46 UTC ( #272457=note: print w/ replies, xml ) Need Help??


in reply to DBI perpare_cached and statment handle gone bad

"Is there any way to force DBI to verify in perpare_cached that the statment handle is still valid and if not re-prepare it?"
You could write a subroutine that re-prepares the handle. That is:

$dbh->execute() || try_again();
From the try_again() function, you could reexecute your statement after running some checks and return the results.

"Would doing so void the performance gains I get from using prepare_cached?"
Not if there is going to be some extended period of time where the query (data from the query) will be reused, IMO.
In all, a lot of what you're worried about is standard error checking. Whether using cached queries or not, you should always check your prepare and/or execute statements. If you are only worried about catching a certain error or a list of errors, you can pass $DBI::errstr and do some parsing to decide whether or not you want to handle the error (e.g re-prepare your statement), die, or continue.
HTH,
Chris
Update: Per runrig's comment, I changed the try_again() to go after the execute. I read to fast and didn't realize the fail was occurring on the execute. This will work (I use it).
Either way, I like the other ideas better (from leriksen and dragonchild), and suggest using those...as I will now start doing!


Comment on Re: DBI perpare_cached and statment handle gone bad
Select or Download Code
Re: Re: DBI perpare_cached and statment handle gone bad
by runrig (Abbot) on Jul 08, 2003 at 23:36 UTC
    my $sth = $dbh->prepare_cached($statement) || try_again();
    That won't do what you think it does. The error is occuring on the execute, not the prepare. And prepare_cached will just return the previously prepared statement handle (which, assuming the database changed, will now be an invalid handle, but a handle nonetheless), and your try_again() will not be called.

    What the OP might want to do, if caching the statement handle is worth the trouble, is cache the handle himself without using prepare_cached, and re-prepare it if it fails on the execute.

    Or use prepare_cached, and if the execute fails, look at the hash ref returned by the CachedKids dbh attribute, delete the statement handle from that, and re-prepare.

      Actually one could use eval to emulate a try-catch scenario (wuch is really one of the main uses of eval)
      eval { # try $sth->execute(); #throw }; if ($@) { #catch if (<error text indicates a recoverable statement handle error) { ...delete cached statement handle, re-prepare SQL and re-execute... } }
        What I'm doing is a step beyond that. I'm using Error (which implements a try-catch type system) and have the following code:
        my $dbh = try { DBI->connect( $conn_string, $props{USER}, $props{PWD}, { PrintError => 0, RaiseError => 1, }, ) } otherwise { throw Error::Database -text => ( $DBI::errstr || $@ || "Unknown Error: '$conn_string'" ); }; $dbh->{HandleError} = sub { throw Error::Database -text => $DBI::er +rstr }; return $dbh;
        I've defined Error::Database as such:
        package Error::Database; ###################################################################### +########## use 5.6.0; use strict; use warnings; ###################################################################### +########## # This is a baseclass I use for extending the standard Error class in +ways that don't matter here. use Error::Base; our @ISA = qw(Error::Base); ###################################################################### +########## sub new { my $class = shift; my $self = $class->SUPER::new(@_) || return undef; my $txt = $self->text; if ($txt =~ /text=([^=]+)./) { $self->{-text} = $1; } elsif ($txt =~ /Message String: (.*?)$/) { $self->{-text} = $1; } return $self; } 1;
        The reason for the regexes is I wanted to strip off meaningless guck to me and only giv eme the good stuff.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://272457]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (12)
As of 2014-12-25 04:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (159 votes), past polls