DBI(3pm) | User Contributed Perl Documentation | DBI(3pm) |
AnyEvent::DBI - asynchronous DBI access
use AnyEvent::DBI; my $cv = AnyEvent->condvar; my $dbh = new AnyEvent::DBI "DBI:SQLite:dbname=test.db", "", ""; $dbh->exec ("select * from test where num=?", 10, sub { my ($dbh, $rows, $rv) = @_; $#_ or die "failure: $@"; print "@$_\n" for @$rows; $cv->broadcast; }); # asynchronously do sth. else here $cv->wait;
This module is an AnyEvent user, you need to make sure that you use and run a supported event loop.
This module implements asynchronous DBI access by forking or executing separate "DBI-Server" processes and sending them requests.
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.
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.
The advantage of this approach is that transactions work as state is preserved.
Example:
$dbh = new AnyEvent::DBI "DBI:mysql:test;mysql_read_default_file=/root/.my.cnf", "", "";
Additional key-value pairs can be used to adjust behaviour:
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.
Regardless of whether "on_connect" is supplied, connect errors will result in "on_error" being called. However, if no "on_connect" callback is supplied, then connection errors are considered fatal. The client will "die" and the "on_error" callback will be called with $fatal true.
When on_connect is supplied, connect error are not fatal and AnyEvent::DBI will not "die". You still cannot, however, use the $dbh object you received from "new" to make requests.
With this argument you can provide your own fork template. This can be useful if you create a lot of "AnyEvent::DBI" handles and want to save memory (And speed up startup) by not having to load "AnyEvent::DBI" again and again into your child processes:
my $template = AnyEvent::Fork ->new # create new template ->require ("AnyEvent::DBI::Slave"); # preload AnyEvent::DBI::Slave module for (...) { $dbh = new AnyEvent::DBI ... fork_template => $template;
When altering your databases with timeouts it is wise to use transactions. If you quit due to timeout while performing insert, update or schema-altering commands you can end up not knowing if the action was submitted to the database, complicating recovery.
Timeout errors are always fatal.
Any additional key-value pairs will be rolled into a hash reference and passed as the final argument to the "DBI->connect (...)" call. For example, to suppress errors on STDERR and send them instead to an AnyEvent::Handle you could do:
$dbh = new AnyEvent::DBI "DBI:mysql:test;mysql_read_default_file=/root/.my.cnf", "", "", PrintError => 0, on_error => sub { $log_handle->push_write ("DBI Error: $@ at $_[1]:$_[2]\n"); };
The callback will be passed the database handle and the attribute's value if successful.
If an error occurs and the "on_error" callback returns, then only $dbh will be passed and $@ contains the error message.
The callback will be called with a weakened AnyEvent::DBI object as the first argument and the result of "fetchall_arrayref" as (or "undef" if the statement wasn't a select statement) as the second argument.
Third argument is the return value from the "DBI->execute" method call.
If an error occurs and the "on_error" callback returns, then only $dbh will be passed and $@ contains the error message.
The callback will be passed the database handle and the attribute's value if successful.
If an error occurs and the "on_error" callback returns, then only $dbh will be passed and $@ contains the error message.
If an error occurs and the "on_error" callback returns, then only $dbh will be passed and $@ contains the error message.
Note that the first argument will be eval'ed to produce the argument list to the func() method. This must be done because the serialization protocol between the AnyEvent::DBI server process and your program does not support the passage of closures.
Here's an example to extend the query language in SQLite so it supports an intstr() function:
$cv = AnyEvent->condvar; $dbh->func ( q{ instr => 2, sub { my ($string, $search) = @_; return index $string, $search; }, }, create_function => sub { return $cv->send ($@) unless $#_; $cv->send (undef, @_[1,2,3]); } ); my ($err,$rc,$errcode,$errstr) = $cv->recv; die $err if defined $err; die "EVAL failed: $errstr" if $errcode; # otherwise, we can ignore $rc and $errcode for this particular func
AnyEvent, DBI, Coro::Mysql.
Marc Lehmann <schmorp@schmorp.de> (current maintainer) http://home.schmorp.de/ Adam Rosenstein <adam@redcondor.com> http://www.redcondor.com/
2021-01-05 | perl v5.32.0 |