NAME

DBD::Gofer - A stateless-proxy driver for communicating with a remote DBI

SYNOPSIS

use DBI;

$original_dsn = "dbi:..."; # your original DBI Data Source Name

$dbh = DBI->connect("dbi:Gofer:transport=$transport;...;dsn=$original_dsn",
                    $user, $passwd, \%attributes);

... use $dbh as if it was connected to $original_dsn ...

The transport=$transport part specifies the name of the module to use to transport the requests to the remote DBI. If $transport doesn't contain any double colons then it's prefixed with DBD::Gofer::Transport::.

The dsn=$original_dsn part must be the last element of the DSN because everything after dsn= is assumed to be the DSN that the remote DBI should use.

The ... represents attributes that influence the operation of the Gofer driver or transport. These are described below or in the documentation of the transport module being used.

DESCRIPTION

DBD::Gofer is a DBI database driver that forwards requests to another DBI driver, usually in a seperate process, often on a separate machine. It tries to be as transparent as possible so it appears that you are using the remote driver directly.

DBD::Gofer is very similar to DBD::Proxy. The major difference is that with DBD::Gofer no state is maintained on the remote end. That means every request contains all the information needed to create the required state. (So, for example, every request includes the DSN to connect to.) Each request can be sent to any available server. The server executes the request and returns a single response that includes all the data.

This is very similar to the way http works as a stateless protocol for the web. Each request from your web browser can be handled by a different web server process.

This may seem like pointless overhead but there are situations where this is a very good thing. Let's consider a specific case.

Imagine using DBD::Gofer with an http transport. Your application calls connect(), prepare("select * from table where foo=?"), bind_param(), and execute(). At this point DBD::Gofer builds a request containing all the information about the method calls. It then uses the httpd transport to send that request to an apache web server.

This 'dbi execute' web server executes the request (using DBI::Gofer::Execute and related modules) and builds a response that contains all the rows of data, if the statement returned any, along with all the attributes that describe the results, such as $sth->{NAME}. This response is sent back to DBD::Gofer which unpacks it and presents it to the application as if it had executed the statement itself.

Okay, but you still don't see the point? Well let's consider what we've gained:

Connection Pooling and Throttling

The 'dbi execute' web server leverages all the functionality of web infrastructure in terms of load balancing, high-availability, firewalls, access management, proxying, caching.

At its most basic level you get a configurable pool of persistent database connections.

Simple Scaling

Got thousands of processes all trying to connect to the database? You can use DBD::Gofer to connect them to your smaller pool of 'dbi execute' web servers instead.

Caching

Not yet implemented, but the single request-response architecture lends itself to caching.

Fewer Network Round-trips

DBD::Gofer sends as few requests as possible.

Thin Clients / Unsupported Platforms

You no longer need drivers for your database on every system. DBD::Gofer is pure perl.

CONSTRAINTS

There are naturally some constraints imposed by DBD::Gofer. But not many:

You can't change database handle attributes after connect()

You can't change database handle attributes after you've connected. Use the connect() call to specify all the attribute settings you want.

This is because it's critical that when a request is complete the database handle is left in the same state it was when first connected.

You can't change statement handle attributes after prepare()

You can't change statment handle attributes after prepare.

You can't use transactions.

AutoCommit only. Transactions aren't supported.

You need to use func() to call driver-private dbh methods

So instead of the new-style:

$dbh->foo_method_name(...)

you need to use the old-style:

$dbh->func(..., 'foo_method_name');

This constraint might be removed in future.

You can't call driver-private sth methods

But that's rarely needed anyway.

Array Methods are not supported

The array methods (bind_param_inout bind_param_array bind_param_inout_array execute_array execute_for_fetch) are not currently supported. Patches welcome, of course.

CAVEATS

A few things to keep in mind when using DBD::Gofer:

Driver-private Database Handle Attributes

Some driver-private dbh attributes may not be available if the driver has not implemented the private_attribute_info() method (added in DBI 1.54).

Driver-private Statement Handle Attributes

Driver-private sth attributes can be set in the prepare() call. TODO

Some driver-private dbh attributes may not be available if the driver has not implemented the private_attribute_info() method (added in DBI 1.54).

Multiple Resultsets

Multiple resultsets are supported if the driver supports the more_results() method.

Use of last_insert_id requires a minor code change

To enable use of last_insert_id you need to indicate to DBD::Gofer that you'd like to use it. You do that my adding a go_last_insert_id_args attribute to the do() or prepare() method calls. For example:

$dbh->do($sql, { go_last_insert_id_args => [...] });

or

$sth = $dbh->prepare($sql, { go_last_insert_id_args => [...] });

The array reference should contains the args that you want passed to the last_insert_id() method.

XXX needs testing

XXX allow $dbh->{go_last_insert_id_args} = [] to enable it by default?

Statement activity that also updates dbh attributes

Some drivers may update one or more dbh attributes after performing activity on a child sth. For example, DBD::mysql provides $dbh->{mysql_insertid} in addition to $sth->{mysql_insertid}. Currently this isn't supported, but probably needs to be.

Methods that report an error always return undef

With DBD::Gofer a method that sets an error always return an undef or empty list. That shouldn't be a problem in practice because the DBI doesn't define any methods that do return meaningful values while also reporting an error.

TRANSPORTS

DBD::Gofer doesn't concern itself with transporting requests and responses to and fro. For that it uses special Gofer transport modules.

Gofer transport modules usually come in pairs: one for the 'client' DBD::Gofer driver to use and one for the remote 'server' end. They have very similar names:

DBD::Gofer::Transport::<foo>
DBI::Gofer::Transport::<foo>

Sometimes the transports on the DBD and DBI sides may have different names. For example DBD::Gofer::Transport::http is typically used with DBI::Gofer::Transport::mod_perl

Bundled Transports

Several transport modules are provided with DBD::Gofer:

null

The null transport is the simplest of them all. It doesn't actually transport the request anywhere. It just serializes (freezes) the request into a string, then thaws it back into a data structure before passing it to DBI::Gofer::Execute to execute. The same freeze and thaw is applied to the results.

The null transport is the best way to test if your application will work with Gofer. Just set the DBI_AUTOPROXY environment variable to "dbi:Gofer:transport=null" (see "DBI_AUTOPROXY" below) and run your application, or ideally its test suite, as usual.

It doesn't take any parameters.

pipeone

The pipeone transport launches a subprocess for each request. It passes in the request and reads the response. The fact that a new subprocess is started for each request proves that the server side is truly stateless. It also makes this transport very slow. It's useful, however, both as a proof of concept and as a base class for the stream driver.

This transport supports a timeout parameter in the dsn which specifies the maximum time it can take to send a requestor receive a response.

stream

The stream driver also launches a subprocess and writes requests and reads responses, like the pipeone transport. In this case, however, the subprocess is expected to handle more that one request. (Though it will be restarted if it exits.)

This is the first transport that is truly useful because it can launch the subprocess on a remote machine using ssh. This means you can now use DBD::Gofer to easily access any databases that's accessible from any system you can login to. You also get all the benefits of ssh, including encryption and optional compression.

This transport supports a timeout parameter in the dsn which specifies the maximum time it can take to send a requestor receive a response.

See "DBI_AUTOPROXY" below for an example.

http

The http driver uses the http protocol to send Gofer requests and receive replies.

It's also very likely that this transport will support safe timeouts in future. XXX

The DBI::Gofer::Transport::mod_perl module implements the corresponding server-side transport.

Other Transports

I know Ask Bjørn Hansen has implemented a transport for the gearman distributed job system. (Not yet on CPAN.)

Implementing a transport is very simple, and more transports are very welcome. Just take a look at any existing transports that are similar to your needs.

CONNECTING

Simply prefix your existing DSN with "dbi:Gofer:transport=$transport;dsn=" where $transport is the name of the Gofer transport you want to use (see "TRANSPORTS"). The transport and dsn attributes must be specified and the dsn attributes must be last.

Other attributes can be specified in the DSN to configure DBD::Gofer and/or the Gofer transport module being used. The two main attributes after transport, are url and policy. These are described below.

Using DBI_AUTOPROXY

The simplest way to try out DBD::Gofer is to set the DBI_AUTOPROXY environment variable. In this case you don't include the dsn= part. For example:

export DBI_AUTOPROXY=dbi:Gofer:transport=null

or, for a more useful example, try:

export DBI_AUTOPROXY=dbi:Gofer:transport=stream;url=ssh:user@example.com

CONFIGURING VIA POLICY

XXX

policy=pedantic is most transparent but slow

policy=classic is a reasonable compromise, and is the default

policy=rush is fastest but may require code changes in application

See DBD::Gofer::Policy::Base for more information.

AUTHOR AND COPYRIGHT

The DBD::Gofer, DBD::Gofer::* and DBI::Gofer::* modules are Copyright (c) 2007 Tim Bunce. Ireland. All rights reserved.

You may distribute under the terms of either the GNU General Public License or the Artistic License, as specified in the Perl README file.

ACKNOWLEDGEMENTS

The development of DBD::Gofer and related modules was sponsored by Shopzilla.com (http://Shopzilla.com), where I currently work.

SEE ALSO

DBI::Gofer::Request, DBI::Gofer::Response, DBI::Gofer::Execute.

DBI::Gofer::Transport::Base, DBD::Gofer::Policy::Base.

DBI

TODO

Random brain dump...

Document policy mechanism

Add mechanism for transports to list config params and for Gofer to apply any that match (and warn if any left over?)

Driver-private sth attributes - set via prepare() - change DBI spec

Timeout for stream and http drivers.

Caching of get_info values

prepare vs prepare_cached

Driver-private sth methods via func? Can't be sure of state?

track installed_methods and install proxies on client side after connect?

add hooks into transport base class for checking & updating a result set cache ie via a standard cache interface such as: http://search.cpan.org/~robm/Cache-FastMmap/FastMmap.pm http://search.cpan.org/~bradfitz/Cache-Memcached/lib/Cache/Memcached.pm http://search.cpan.org/~dclinton/Cache-Cache/ http://search.cpan.org/~cleishman/Cache/ Also caching instructions could be passed through the httpd transport layer in such a way that appropriate http cache headers are added to the results so that web caches (squid etc) could be used to implement the caching. (MUST require the use of GET rather than POST requests.)

Neat way for $h->trace to enable transport tracing.

cpanm DBI

perl -MCPAN -e shell
install DBI