AnyEvent-DBI
view release on metacpan or search on metacpan
- do not leave zombie processes (Adam Rosenstein).
2.1 Sat Oct 30 22:22:05 CEST 2010
- no longer kill -9 the child, just kill -TERM and close the connection,
to avoid database corruption - this also works around a perl bug
(global destruction).
- convert to the faster AE API - major speedup.
- use common::sense.
2.0 Mon Jun 29 10:18:58 CEST 2009
- INCOMPATIBLE CHANGE: callbacks now are passed the $dbh
as first argument, always.
- INCOMPATIBLE CHANGE: really pass rv as third argument to exec
callbacks, as documented but not implemented for 1.1.
- thanks to viacheslav.t for testing.
- major patch by Adam Rosenstein:
- add an on_connect callback (for reliable failure notification)
- add timeouts to connect and exec.
- reaps server processes if you undef your AE::DBI handle and keep
running.
- option to start the server via exec, otherwise try to emulate
close-on-exec behavior.
- add the begin_work/commit/rollback methods required to actually use
transactions.
- add accessors for database handle attibutes such as AutoCommit,
RaiseError, etc.
- add support for the func() method to interact directly with a driver.
- add more/real tests.
1.1 Sat Dec 20 22:28:11 CET 2008
- INCOMPATIBLE CHANGE: pass result value in place of %extra
to callbacks.
- do not call fetchrow_arrayref on non-select statements.
- do not die on non-fatal errors, unless there is no error callback
(reported by Adam Rosenstein).
1.0 Mon Jun 9 16:27:36 CEST 2008
- original version, an AnyEvent::HTTP clone.
It means that you can run DBI requests in parallel to other tasks.
With DBD::mysql, the overhead for very simple statements
("select 0") is somewhere around 50% compared to an explicit
prepare_cached/execute/fetchrow_arrayref/finish combination. With
DBD::SQlite3, it's more like a factor of 8 for this trivial statement.
=head2 ERROR HANDLING
This module defines a number of functions that accept a callback
argument. All callbacks used by this module get their AnyEvent::DBI handle
object passed as first argument.
If the request was successful, then there will be more arguments,
otherwise there will only be the C<$dbh> argument and C<$@> contains an
error message.
A convenient way to check whether an error occurred is to check C<$#_> -
if that is true, then the function was successful, otherwise there was an
error.
=over 4
=item on_error => $callback->($dbh, $filename, $line, $fatal)
When an error occurs, then this callback will be invoked. On entry, C<$@>
is set to the error message. C<$filename> and C<$line> is where the
original request was submitted.
If the fatal argument is true then the database connection is shut down
and your database handle became invalid. In addition to invoking the
C<on_error> callback, all of your queued request callbacks are called
without only the C<$dbh> argument.
If omitted, then C<die> will be called on any errors, fatal or not.
=item on_connect => $callback->($dbh[, $success])
If you supply an C<on_connect> callback, then this callback will be
invoked after the database connect attempt. If the connection succeeds,
C<$success> is true, otherwise it is missing and C<$@> contains the
C<$DBI::errstr>.
sub _error {
my ($self, $error, $filename, $line, $fatal) = @_;
if ($fatal) {
delete $self->{tw};
delete $self->{rw};
delete $self->{ww};
delete $self->{fh};
# for fatal errors call all enqueued callbacks with error
while (my $req = shift @{$self->{queue}}) {
local $@ = $error;
$req->[0]->($self);
}
$self->kill_child;
}
local $@ = $error;
if ($self->{on_error}) {
It means that you can run DBI requests in parallel to other tasks.
With DBD::mysql, the overhead for very simple statements ("select 0") is
somewhere around 50% compared to an explicit
prepare_cached/execute/fetchrow_arrayref/finish combination. With
DBD::SQlite3, it's more like a factor of 8 for this trivial statement.
ERROR HANDLING
This module defines a number of functions that accept a callback
argument. All callbacks used by this module get their AnyEvent::DBI
handle object passed as first argument.
If the request was successful, then there will be more arguments,
otherwise there will only be the $dbh argument and $@ contains an error
message.
A convenient way to check whether an error occurred is to check $#_ - if
that is true, then the function was successful, otherwise there was an
error.
Additional key-value pairs can be used to adjust behaviour:
on_error => $callback->($dbh, $filename, $line, $fatal)
When an error occurs, then this callback will be invoked. On
entry, $@ is set to the error message. $filename and $line is
where the original request was submitted.
If the fatal argument is true then the database connection is
shut down and your database handle became invalid. In addition
to invoking the "on_error" callback, all of your queued request
callbacks are called without only the $dbh argument.
If omitted, then "die" will be called on any errors, fatal or
not.
on_connect => $callback->($dbh[, $success])
If you supply an "on_connect" callback, then this callback will
be invoked after the database connect attempt. If the connection
succeeds, $success is true, otherwise it is missing and $@
contains the $DBI::errstr.
( run in 1.287 second using v1.01-cache-2.11-cpan-9b1e4054eb1 )