Use Cases

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.

Advantages

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

Client-side caching is as simple as adding ""cache=1"" to the DSN. This feature alone can be worth using DBD::Gofer for.

Fewer Network Round-trips

DBD::Gofer sends as few requests as possible (dependent on the policy being used).

Thin Clients / Unsupported Platforms

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

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.

An exception is made for attributes with names starting ""private_"": They can be set after connect() but the change is only applied locally.

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

You can't change statement handle attributes after prepare.

An exception is made for attributes with names starting ""private_"": They can be set after prepare() but the change is only applied locally.

You can't use transactions

AutoCommit only. Transactions aren't supported.

(In theory transactions could be supported when using a transport that maintains a connection, like "stream" does. If you're interested in this please get in touch via dbi-dev@perl.org)

You can't call driver-private sth methods

But that's rarely needed anyway.

Temporary tables, locks, and other per-connection persistent state

You shouldn't expect any per-session state to persist between requests. This includes locks and temporary tables.

Because the server-side may execute your requests via a different database connections, you can't rely on any per-connection persistent state, such as temporary tables, being available from one request to the next.

This is an easy trap to fall into. A good way to check for this is to test your code with a Gofer policy package that sets the "connect_method" policy to 'connect' to force a new connection for each request. The "pedantic" policy does this.

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 sth 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 only if the driver supports the more_results() method (an exception is made for DBD::Sybase).

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 mysql_insertid is supported via a hack but a more general mechanism is needed for other drivers to use.

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 return meaningful values while also reporting an error.

Subclassing only applies to client-side

The RootClass and DbTypeSubclass attributes are not passed to the Gofer server.

last_insert_id

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.

execute_for_fetch

The array methods bind_param_array() and execute_array() are supported. When execute_array() is called the data is serialized and executed in a single round-trip to the Gofer server. This makes it very fast, but requires enough memory to store all the serialized data.

The execute_for_fetch() method currently isn't optimised, it uses the DBI fallback behaviour of executing each tuple individually. (It could be implemented as a wrapper for execute_array() - patches welcome.)

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;policy=pedantic"" (see "Using 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 ensures that the server side is truly stateless. While this does make the transport very slow, it is useful as a way to test that your application doesn't depend on per-connection state, such as temporary tables, persisting between requests.

It's also useful both as a proof of concept and as a base class for the stream driver.

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

See "Using DBI_AUTOPROXY" below for an example.

Other Transports

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

http

See the GoferTransport-http distribution on CPAN: http://search.cpan.org/dist/GoferTransport-http/

Gearman

I know Ask Bjørn Hansen has implemented a transport for the "gearman" distributed job system, though it's not on CPAN at the time of writing this.

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"

Connection Attributes

These attributes can be specified in the DSN. They can also be passed in the \%attr parameter of the DBI connect method by adding a ""go_"" prefix to the name.

transport

Specifies the Gofer transport class to use. Required. See "TRANSPORTS" above.

If the value does not include "::" then ""DBD::Gofer::Transport::"" is prefixed.

The transport object can be accessed via $h->{go_transport}.

dsn

Specifies the DSN for the remote side to connect to. Required, and must be last.

url

Used to tell the transport where to connect to. The exact form of the value depends on the transport used.

policy

Specifies the policy to use. See "CONFIGURING BEHAVIOUR POLICY".

If the value does not include "::" then ""DBD::Gofer::Policy"" is prefixed.

The policy object can be accessed via $h->{go_policy}.

timeout

Specifies a timeout, in seconds, to use when waiting for responses from the server side.

retry_limit

Specifies the number of times a failed request will be retried. Default is 0.

retry_hook

Specifies a code reference to be called to decide if a failed request should be retried. The code reference is called like this:

  $transport = $h->{go_transport};
  $retry = $transport->go_retry_hook->($request, $response, $transport);

If it returns true then the request will be retried, up to the "retry_limit". If it returns a false but defined value then the request will not be retried. If it returns undef then the default behaviour will be used, as if "retry_hook" had not been specified.

The default behaviour is to retry requests where $request->is_idempotent is true, or the error message matches "/induced by DBI_GOFER_RANDOM/".

cache

Specifies that client-side caching should be performed. The value is the name of a cache class to use.

Any class implementing get($key) and set($key, $value) methods can be used. That includes a great many powerful caching classes on CPAN, including the Cache and Cache::Cache distributions.

You can use ""cache=1"" is a shortcut for ""cache=DBI::Util::CacheMemory"". See DBI::Util::CacheMemory for a description of this simple fast default cache.

The cache object can be accessed via $h->go_cache. For example:

    $dbh->go_cache->clear; # free up memory being used by the cache

The cache keys are the frozen (serialized) requests, and the values are the frozen responses.

The default behaviour is to only use the cache for requests where $request->is_idempotent is true (i.e., the dbh has the ReadOnly attribute set or the SQL statement is obviously a SELECT without a FOR UPDATE clause.)

For even more control you can use the "go_cache" attribute to pass in an instantiated cache object. Individual methods, including prepare(), can also specify alternative caches via the "go_cache" attribute. For example, to specify no caching for a particular query, you could use

    $sth = $dbh->prepare( $sql, { go_cache => 0 } );

This can be used to implement different caching policies for different statements.

It's interesting to note that DBD::Gofer can be used to add client-side caching to any (gofer compatible) application, with no code changes and no need for a gofer server. Just set the DBI_AUTOPROXY environment variable like this:

    DBI_AUTOPROXY='dbi:Gofer:transport=null;cache=1'