view release on metacpan or  search on metacpan

README  view on Meta::CPAN

NAME
    AnyEvent::DBI - asynchronous DBI access

SYNOPSIS
       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;

DESCRIPTION
    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.

  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.

  METHODS
    $dbh = new AnyEvent::DBI $database, $user, $pass, [key => value]...
        Returns a database handle for the given database. Each database
        handle has an associated server process that executes statements in
        order. If you want to run more than one statement in parallel, you
        need to create additional database handles.

        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