AnyEvent-DBI
view release on metacpan or search on metacpan
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:
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.
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.
fork_template => $AnyEvent::Fork-object
"AnyEvent::DBI" uses "AnyEvent::Fork->new" to create the
database slave, which in turn either "exec"'s a new process
(similar to the old "exec_server" constructor argument) or uses
a process forked early (see AnyEvent::Fork::Early).
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;
timeout => seconds
If you supply a timeout parameter (fractional values are
supported), then a timer is started any time the DBI handle
expects a response from the server. This includes connection
setup as well as requests made to the backend. The timeout spans
the duration from the moment the first data is written (or
queued to be written) until all expected responses are returned,
but is postponed for "timeout" seconds each time more data is
returned from the server. If the timer ever goes off then a
fatal error is generated. If you have an "on_error" handler
installed, then it will be called, otherwise your program will
die().
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");
};
$dbh->on_error ($cb->($dbh, $filename, $line, $fatal))
Sets (or clears, with "undef") the "on_error" handler.
$dbh->timeout ($seconds)
Sets (or clears, with "undef") the database timeout. Useful to
extend the timeout when you are about to make a really long query.
$dbh->attr ($attr_name[, $attr_value], $cb->($dbh, $new_value))
An accessor for the database handle attributes, such as
"AutoCommit", "RaiseError", "PrintError" and so on. If you provide
an $attr_value (which might be "undef"), then the given attribute
will be set to that value.
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.
$dbh->exec ("statement", @args, $cb->($dbh, \@rows, $rv))
Executes the given SQL statement with placeholders replaced by
@args. The statement will be prepared and cached on the server side,
so using placeholders is extremely important.
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.
$dbh->stattr ($attr_name, $cb->($dbh, $value))
( run in 1.549 second using v1.01-cache-2.11-cpan-39bf76dae61 )