Manpages

DBI::DBD

NAME

SYNOPSIS

  perldoc DBI::DBD

VERSION and VOLATILITY

  $Revision: 11.2 $
  $Date: 2001/08/24 22:10:44 $

The changes will occur both because the DBI specification is changing and hence the requirements on DBD drivers change, and because feedback from people reading this document will suggest improvements to it.

Please read the DBI documentation first and fully, including the DBI FAQ. The reread the DBI specification again as you're reading this. It'll help.

This document is a patchwork of contributions from various authors. More contributions (preferably as patches) are very welcome.  

DESCRIPTION

This is a guide. Few (if any) of the statements in it are completely authoritative under all possible circumstances. This means you will need to use judgement in applying the guidelines in this document. If in any doubt at all, please do contact the dbi-dev mailing list (details given below) where Tim Bunce and other driver authors can help.

The primary web-site for locating DBI software and information is

  http://www.symbolstone.org/technology/perl/DBI

You can join these lists by accessing the web-site <http://www.isc.org/dbi-lists.html>. The lists are closed so you cannot send email to any of the lists unless you join the list first.

You should also consider monitoring the comp.lang.perl.* newsgroups.  

BOOK

REGISTERING A NEW DRIVER

Locating drivers

  http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces/DBI

  http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces/DBD

Registering a new driver

CREATING A NEW DRIVER USING PURE PERL

As an example we take a look at the DBD::File driver, a driver for accessing plain files as tables, which is part of the DBD::CSV package. In what follows I assume the name "Driver" for your new package: The least thing we have to implement are the files "Makefile.PL" and "Driver.pm".  

Makefile.PL

Of special importance for DBI drivers is the postamble method from the "ExtUtils::MM_Unix" man page. And for Emacs users I recommend the libscan method.

Now an example, I use the word "Driver" wherever you should insert your drivers name:

  # -*- perl -*-

  use DBI 1.03;
  use DBI::DBD;
  use ExtUtils::MakeMaker;

  ExtUtils::MakeMaker::WriteMakefile(
      'NAME'         => 'DBD::Driver',
      'VERSION_FROM' => 'Driver.pm',
      'INC'          => $DBI_INC_DIR,
      'dist'         => { 'SUFFIX'   => '.gz',
                            'COMPRESS' => 'gzip -9f' },
      'realclean'    => '*.xsi'
  );

  package MY;
  sub postamble { dbd_postamble(@_); }
  sub libscan {
      my ($self, $path) = @_;
      ($path =~ m/\~$/) ? undef : $path;
  }

README file

MANIFEST

lib/Bundle/DBD/Driver.pm

        perl -MCPAN -e 'install Bundle::DBD::Driver'

A suitable skeleton for this file is shown below. The prerequisite modules are listed in the CONTENTS section, with the official name of the module followed by a dash and an informal name or description. Listing Bundle::DBI as the main pre-requisite simplifies life. Don't forget to list your driver. Note that unless the DBMS is itself a Perl module, you cannot list it as a pre-requisite in this file. You are strongly advised to keep the version of the bundle in sync with the version of your driver. You might want to add configuration management, copyright, and licencing information at the top.

  package Bundle::DBD::Driver;

  $VERSION = '0.01';

  1;

  __END__

  =head1 NAME

  Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules

  =head1 SYNOPSIS

  C<perl -MCPAN -e 'install Bundle::DBD::Driver'>

  =head1 CONTENTS

  Bundle::DBI  - Bundle for DBI by TIMB (Tim Bunce)

  DBD::Driver  - DBD::Driver by YOU (Your Name)

  =head1 DESCRIPTION

  This bundle includes all the modules used by the Perl Database
  Interface (DBI) driver for Driver (DBD::Driver), assuming the
  use of DBI version 1.13 or later, created by Tim Bunce.

  If you've not previously used the CPAN module to install any
  bundles, you will be interrogated during its setup phase.
  But when you've done it once, it remembers what you told it.
  You could start by running:

    C<perl -MCPAN -e 'install Bundle::CPAN'>

  =head1 SEE ALSO

  Bundle::DBI

  =head1 AUTHOR

  Your Name E<lt>F<you@yourdomain.com>E<gt>

  =head1 THANKS

  This bundle was created by ripping off Bundle::libnet created by
  Graham Barr E<lt>F<gbarr@ti.com>E<gt>, and radically simplified
  with some information from Jochen Wiedmann E<lt>F<joe@ispsoft.de>E<gt>.
  The template was then included in the DBI::DBD documentation by
  Jonathan Leffler E<lt>F<jleffler@informix.com>E<gt>.

  =cut

Driver.pm

It will also define a package DBD::Driver::dr (with methods connect(), data_sources() and disconnect_all()), and a package DBD::Driver::db (which will define a function prepare() etc), and a package DBD::Driver::st with methods execute(), fetch() and the like.

The Driver.pm file will also contain the documentation specific to DBD::Driver in the format used by perldoc.

Now let's take a closer look at an excerpt of File.pm as an example. We ignore things that are common to any module (even non-DBI(D) modules) or really specific for the DBD::File package.

The header

  package DBD::File;

  use strict;
  use vars qw($err $errstr $state $drh);

  $err = 0;             # holds error code   for DBI::err
  $errstr = "";         # holds error string for DBI::errstr
  $sqlstate = "";       # holds SQL state for    DBI::state

These variables are used for storing error states and messages. However, it is crucial to understand that you must not modify them directly; instead use the event method, see below.

  $drh = undef;         # holds driver handle once initialized

This is where the driver handle will be stored, once created. Note, that you may assume, there's only one handle for your driver.

The driver constructor

  sub driver
  {
      return $drh if $drh;      # already created - return same one
      my ($class, $attr) = @_;

      $class .= "::dr";

      # not a 'my' since we use it above to prevent multiple drivers
      $drh = DBI::_new_drh($class, {
          'Name'        => 'File',
          'Version'     => $VERSION,
          'Err'         => \$DBD::File::err,
          'Errstr'      => \$DBD::File::errstr,
          'State'       => \$DBD::File::state,
          'Attribution' => 'DBD::File by Jochen Wiedmann',
      });

      return $drh;
  }

The driver method is the driver handle constructor. It's a reasonable example of how DBI implements its handles. There are three kinds: driver handles (typically stored in $drh, from now on called "drh"), database handles (from now on called "dbh" or $dbh) and statement handles, (from now on called "sth" or $sth).

The prototype of DBI::_new_drh is

  $drh = DBI::_new_drh($class, $attr1, $attr2);

with the following arguments:

$class

is typically your drivers class, e.g., ``DBD::File::dr'', passed as first argument to the driver method.

$attr1

is a hash ref to attributes like Name, Version, Err, Errstr State and Attributrion. These are processed and used by DBI, you better not make any assumptions on them nor should you add private attributes here.

$attr2

This is another (optional) hash ref with your private attributes. DBI will leave them alone.

The DBI::new_drh method and the driver method both return "undef" for failure (in which case you must look at $DBI::err and $DBI::errstr, because you have no driver handle).

The database handle constructor

The next lines of code look as follows:

  package DBD::Driver::dr; # ====== DRIVER ======

  $DBD::Driver::dr::imp_data_size = 0;

Note that no @ISA is needed here, or for the other DBD::Driver::* classes, because the DBI takes care of that for you when the driver is loaded.

The database handle constructor is a driver method, thus we have to change the namespace.

  sub connect
  {
      my ($drh, $dbname, $user, $auth, $attr) = @_;

      # Some database specific verifications, default settings
      # and the like following here. This should only include
      # syntax checks or similar stuff where it's legal to
      # 'die' in case of errors.

      # create a 'blank' dbh (call superclass constructor)
      my $dbh = DBI::_new_dbh($drh, {
          'Name'         => $dbname,
          'USER'         => $user,
          'CURRENT_USER' => $user,
      });

      # Process attributes from the DSN; we assume ODBC syntax
      # here, that is, the DSN looks like var1=val1;...;varN=valN

      my $var;
      foreach $var (split(/;/, $dbname)) {
          if ($var =~ m/(.*?)=(,*)/) {
              # Not !!! $dbh->{$var} = $val;
              $dbh->STORE($var, $val);
          }
      }
      $dbh;
  }

This is mostly the same as in the driver handle constructor above. The arguments are described in the DBI man page. See DBI(3). The constructor is called, returning a database handle. The constructors prototype is

  $dbh = DBI::_new_dbh($drh, $attr1, $attr2);

with the same arguments as in the driver handle constructor, the exception being $class replaced by $drh.

Note the use of the STORE method for setting the dbh attributes. That's because within the driver code, the handle object you have is the 'inner' handle of a tied hash, not the outer handle that the users of your driver have.

Because you have the inner handle, tie magic doesn't get invoked when you get or set values in the hash. This is often very handy for speed when you want to get or set simple non-special driver-specific attributes.

However, some attribute values, such as those handled by the DBI like PrintError, don't actually exist in the hash and must be read via $h->FETCH($attrib) and set via $h->STORE($attrib, $value). If in any doubt, use these methods.

Error handling

It is quite likely that something fails in the connect method. With DBD::File for example, you might catch an error when setting the current directory to something not existant by using the f_dir attribute.

To report an error, you use the "DBI::set_err" function/method:

  $h->DBI::set_err($errcode, $errmsg);

This will ensure that the error is recorded correctly and that RaiseError and PrintError etc are handled correctly. Typically you'll always use the method instance, aka your method's first argument.

As set_err always returns undef your error handling code can usually be simplified to something like this:

  return $h->DBI::set_err($errcode, $errmsg) if ...;

Other driver handle methods

may follow here. In particular you should consider a data_sources method, and a (possibly empty) disconnect_all method. See DBI(3).

The statement handle constructor

There's nothing much new in the statement handle constructor.

  package DBD::Driver::db; # ====== DATABASE ======

  $DBD::Driver::db::imp_data_size = 0;

  sub prepare
  {
      my ($dbh, $statement, @attribs) = @_;

      # create a 'blank' sth
      my $sth = DBI::_new_sth($dbh, {
          'Statement' => $statement,
          });

      # Setup module specific data
      $sth->STORE('driver_params', []);
      $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//));

      $sth;
  }

This is still the same: Check the arguments and call the super class constructor DBI::_new_sth. Note the prefix driver_ in the attribute names: It is required that your private attributes are lowercased and use such a prefix. See the DBI manual.

Note that we parse the statement here in order to setup the attribute NUM_OF_PARAMS. We could as well do this in the execute method below, the DBI specs explicitly allow to defer this. However, one could not call bind_param in that case.

Transaction handling

Pure Perl drivers will rarely support transactions. Thus you're commit and rollback methods will typically be quite simple:

  sub commit
  {
      my ($dbh) = @_;
      if ($dbh->FETCH('Warn')) {
          warn("Commit ineffective while AutoCommit is on");
      }
      1;
  }

  sub rollback {
      my ($dbh) = @_;
      if ($dbh->FETCH('Warn')) {
          warn("Rollback ineffective while AutoCommit is on");
      }
      0;
  }

The STORE and FETCH methods

These methods (that we have already used, see above) are called for you, whenever the user does a

  $dbh->{$attr} = $val;

or, respectively,

  $val = $dbh->{$attr};

See perltie(1) for details on tied hash refs to understand why these methods are required.

The DBI will handle most attributes for you, in particular attributes like RaiseError or PrintError. All you have to do handle your driver's private attributes and any attributes, like AutoCommit, that the DBI can't handle for you. A good example might look like this:

  sub STORE
  {
      my ($dbh, $attr, $val) = @_;
      if ($attr eq 'AutoCommit') {
          # AutoCommit is currently the only standard attribute we have
          # to consider.
          if (!$val) { die "Can't disable AutoCommit"; }
          return 1;
      }
      if ($attr =~ m/^driver_/) {
          # Handle only our private attributes here
          # Note that we could trigger arbitrary actions.
          # Ideally we should catch unknown attributes.
          $dbh->{$attr} = $val; # Yes, we are allowed to do this,
          return 1;             # but only for our private attributes
      }
      # Else pass up to DBI to handle for us
      $dbh->SUPER::STORE($attr, $val);
  }

  sub FETCH
  {
      my ($dbh, $attr) = @_;
      if ($attr eq 'AutoCommit') { return 1; }
      if ($attr =~ m/^driver_/) {
          # Handle only our private attributes here
          # Note that we could trigger arbitrary actions.
          return $dbh->{$attr}; # Yes, we are allowed to do this,
                                # but only for our private attributes
      }
      # Else pass up to DBI to handle
      $dbh->SUPER::FETCH($attr);
  }

The DBI will actually store and fetch driver-specific attributes (with all lowercase names) without warning or error, so there's actually no need to implement driver-specific any code in your FETCH and STORE methods unless you need extra logic/checks, beyond getting or setting the value.

Other database handle methods

may follow here. In particular you should consider a (possibly empty) disconnect method, a quote method (if DBI's default isn't good for you).

The execute method

This is perhaps the most difficult method because we have to consider parameter bindings here. We present a simplified implementation by using the driver_params attribute from above:

  package DBD::Driver::st;

  $DBD::Driver::st::imp_data_size = 0;

  sub bind_param
  {
      my ($sth, $pNum, $val, $attr) = @_;
      my $type = (ref $attr) ? $attr->{TYPE} : $attr;
      if ($type) {
          my $dbh = $sth->{Database};
          $val = $dbh->quote($sth, $type);
      }
      my $params = $sth->FETCH('driver_params');
      $params->[$pNum-1] = $val;
      1;
  }

  sub execute
  {
      my ($sth, @bind_values) = @_;
      my $params = (@bind_values) ?
          \@bind_values : $sth->FETCH('driver_params');
      my $numParam = $sth->FETCH('NUM_OF_PARAMS');
      if (@$params != $numParam) { ... }
      my $statement = $sth->{'Statement'};
      for (my $i = 0;  $i < $numParam;  $i++) {
          $statement =~ s/?/$params->[$i]/e;
      }
      # Do anything ... we assume that an array ref of rows is
      # created and store it:
      $sth->{'driver_data'} = $data;
      $sth->{'driver_rows'} = @$data; # number of rows
      $sth->STORE('NUM_OF_FIELDS') = $numFields;
      @$data || '0E0';
  }

Things you should note here: We setup the NUM_OF_FIELDS attribute here, because this is essential for bind_columns to work. And we use attribute $sth-{'Statement'}> which we have created within prepare. The attribute $sth-{'Database'}>, which is nothing else than the dbh, was automatically created by DBI.

Finally note that we return the string '0E0' instead of the number 0, so that

  if (!$sth->execute()) { die $sth->errstr }

works.

Fetching data

We need not implement the methods fetchrow_array, fetchall_arrayref, ... because these are already part of DBI. All we need is the method fetchrow_arrayref:

  sub fetchrow_arrayref
  {
      my ($sth) = @_;
      my $data = $sth->FETCH('driver_data');
      my $row = shift @$data;
      if (!$row) { return undef; }
      if ($sth->FETCH('ChopBlanks')) {
          map { $_ =~ s/\s+$//; } @$row;
      }
      return $sth->_set_fbav($row);
  }
  *fetch = \&fetchrow_arrayref; # required alias for fetchrow_arrayref

  sub rows { my ($sth) = @_; $sth->FETCH('driver_rows'); }

Note the use of the method _set_fbav: This is required so that bind_col and bind_columns work.

Fixing the broken implementation for correct handling of quoted question marks is left as an exercise to the reader. :-)

Statement attributes

The main difference between dbh and sth attributes is, that you should implement a lot of attributes here that are required by the DBI: For example NAME, NULLABLE, TYPE, ...

Besides that the STORE and FETCH methods are mainly the same as above for dbh's.

Other statement methods

A trivial "finish" method to discard the stored data and do $sth->SUPER::finish;

A "table_info" method to return details of available tables.

A "type_info_all" method to return details of supported types.

And perhaps some other methods that are not part of the DBI specs, in particular make metadata available. Considering Tim's last articles do yourself a favour and follow the ODBC driver.

Tests

In particular, most of the tests should be run in the t sub-directory, and should simply produce an 'ok' when run under 'make test'. For details on how this is done, see the Camel book and the section in Chapter 7, ``The Standard Perl Library'' on Test::Harness.

The tests may need to adapt to the type of database which is being used for testing, and to the privileges of the user testing the driver.

The DBD::Informix test code has to adapt in a number of places to the type of database to which it is connected as different Informix databases have different capabilities.

        [...More info TBS...]

CREATING A NEW DRIVER USING C/XS

The de facto reference driver has been the one for DBD::Oracle, written by Tim Bunce who is also the author of the DBI package. The DBD::Oracle module is a good example of a driver implemented around a C-level API.

Nowadays it it seems better to base on DBD::ODBC, another driver maintained by Tim and Jeff Urlwin, because it offers a lot of metadata and seems to become the guideline for the future development. (Also as DBD::Oracle digs deeper into the Oracle 8 OCI interface it'll get even more hairly than it is now.)

The DBD::Informix driver is a good reference for a driver implemented using 'embedded SQL'. DBD::Ingres may also be worth a look.

        [...More info TBS...]

REQUIREMENTS ON A DRIVER

CODE TO BE WRITTEN

Driver.pm

Driver.xs

Driver.h

dbdimp.h

dbdimp.c

Makefile.PL

README

MANIFEST

lib/Bundle/DBD/Driver.pm

Driver.pm

*

The variables $DBD::File::dr|db|st::imp_data_size are not defined here, but in the XS code, because they declare the size of certain C structures.

*

Some methods are typically moved to the XS code, in particular prepare, execute, disconnect, disconnect_all and the STORE and FETCH methods.

*

Other methods are still part of "Driver.pm", but have callbacks in the XS code.

Now let's take a closer look at an excerpt of Oracle.pm (around version 0.54, prior to Oracle 8 support) as an example. We ignore things that are already discussed for Pure Perl drivers or really Oracle specific.

The database handle constructor

  sub connect
  {
      my ($drh, $dbname, $user, $auth) = @_;

      # Some database specific verifications, default settings
      # and the like following here. This should only include
      # syntax checks or similar stuff where it's legal to
      # 'die' in case of errors.

      # create a 'blank' dbh (call superclass constructor)
      my $dbh = DBI::_new_dbh($drh, {
          'Name'         => $dbname,
          'USER'         => $user,
          'CURRENT_USER' => $user,
          });

      # Call Oracle OCI orlon func in Oracle.xs file
      # and populate internal handle data.
      DBD::Oracle::db::_login($dbh, $dbname, $user, $auth)
          or return undef;

      $dbh;
  }

This is mostly the same as in the Pure Perl case, the exception being the use of the private _login callback: This will really connect to the database. It is implemented in Driver.xst (you should not implement it) and calls dbd_db_login from dbdimp.c. See below for details.

Since the DBI::_new_xxh methods can't fail in normal situations, we don't both checking $dbh before calling _login.

The statement handle constructor

There's nothing much new in the statement handle constructor. Like the connect method it now has a C callback:

  package DBD::Oracle::db; # ====== DATABASE ======
  use strict;

  sub prepare
  {
      my ($dbh, $statement, @attribs) = @_;

      # create a 'blank' sth
      my $sth = DBI::_new_sth($dbh, {
          'Statement' => $statement,
          });

      # Call Oracle OCI oparse func in Oracle.xs file.
      # (This will actually also call oopen for you.)
      # and populate internal handle data.

      DBD::Oracle::st::_prepare($sth, $statement, @attribs)
          or return undef;

      $sth;
  }

Driver.xs

  #include "Driver.h"

  DBISTATE_DECLARE;

  INCLUDE: Driver.xsi

  MODULE = DBD::Driver    PACKAGE = DBD::Driver::db

  /* Non-standard dbh XS methods following here, if any.       */
  /* Currently this includes things like _list_tables from     */
  /* DBD::mSQL and DBD::mysql.                                 */

  MODULE = DBD::Driver    PACKAGE = DBD::Driver::st

  /* Non-standard sth XS methods following here, if any.       */
  /* In particular this includes things like _list_fields from */
  /* DBD::mSQL and DBD::mysql for accessing metadata.          */

Driver.h

  #define NEED_DBIXS_VERSION 93

  #include <DBIXS.h>      /* installed by the DBI module  */

  #include "dbdimp.h"

  #include <dbd_xsh.h>    /* installed by the DBI module  */

Implementation header dbdimp.h

First it defines data structures for your private part of the handles.

Second it defines macros that rename the generic names like dbd_db_login to database specific names like ora_db_login. This avoids name clashes and enables use of different drivers when you work with a statically linked perl.

It also will have the important task of disabling XS methods that you don't want to implement.

Finally, the macros will also be used to select alternate implementations of some functions. For example, the currently defined "dbd_db_login" function is not passed the attribute hash. In future, if a dbd_db_login6 macro is defined (for a function with 6 arguments), it will be used instead with the attribute hash passed at the sixth argument.

People liked to just pick Oracle's dbdimp.c and use the same names, structures and types. I strongly recommend against that: At first glance this saves time, but your implementation will be less readable. It was just a hell when I had to separate DBI specific parts, Oracle specific parts, mSQL specific parts and mysql specific parts in DBD::mysql's dbdimp.h and dbdimp.c. (DBD::mysql was a port of DBD::mSQL which was based on DBD::Oracle.) This part of the driver is your exclusive part. Rewrite it from scratch, so it will be clean and short, in other words: A better piece of code. (Of course have an eye at other people's work.)

  struct imp_drh_st {
      dbih_drc_t com;           /* MUST be first element in structure   */

      /* Insert your driver handle attributes here */
  };

  struct imp_dbh_st {
      dbih_dbc_t com;           /* MUST be first element in structure   */

      /* Insert your database handle attributes here */
  };

  struct imp_sth_st {
      dbih_stc_t com;           /* MUST be first element in structure   */

      /* Insert your statement handle attributes here */
  };

  /*  Rename functions for avoiding name clashes; prototypes are  */
  /*  in dbd_xst.h                                                */
  #define dbd_init          ora_init
  #define dbd_db_login      ora_db_login
  #define dbd_db_do        ora_db_do
  ... many more here ...

Implementation source dbdimp.c

Note that most people are still using Kernighan & Ritchie syntax here. I personally don't like this and especially in this documentation it cannot be of harm, so let's use ANSI. Finally Tim Bunce has announced interest in moving the DBI sources to ANSI as well.

Initialization

  #include "Driver.h"

  DBISTATE_DECLARE;

  void dbd_init(dbistate_t* dbistate)
  {
      DBIS = dbistate;  /*  Initialize the DBI macros  */
  }

dbd_init will be called when your driver is first loaded. These statements are needed for use of the DBI macros. They will include your private header file dbdimp.h in turn.

do_error

You need a function to handle recording of errors. You can call it whatever you like, but we'll call it "do_error" here.

  void do_error(SV* h, int rc, char* what) {

Note that h is a generic handle, may it be a driver handle, a database or a statement handle.

  D_imp_xxh(h);

This macro will declare and initialize a variable imp_xxh with a pointer to your private handle pointer. You may cast this to to imp_drh_t, imp_dbh_t or imp_sth_t.

  SV *errstr = DBIc_ERRSTR(imp_xxh);
  sv_setiv(DBIc_ERR(imp_xxh), (IV)rc);  /* set err early        */
  sv_setpv(errstr, what);
  DBIh_EVENT2(h, ERROR_event, DBIc_ERR(imp_xxh), errstr);

Note the use of the macros DBIc_ERRSTR and DBIc_ERR for accessing the handles error string and error code.

The macro DBIh_EVENT2 will ensure that the attributes RaiseError and PrintError work: That's all what you have to deal with them. :-)

  if (dbis->debug >= 2)
      fprintf(DBILOGFP, "%s error %d recorded: %s\n",
          what, rc, SvPV(errstr,na));

That's the first time we see how debug/trace logging works within a DBI driver. Make use of this as often as you can!

dbd_db_login

  int dbd_db_login(SV* dbh, imp_dbh_t* imp_dbh, char* dbname,
                   char* user, char* auth);

This function will really connect to the database. The argument dbh is the database handle. imp_dbh is the pointer to the handles private data, as is imp_xxx in do_error above. The arguments dsn, user and auth correspond to the arguments of the driver handles connect method.

You will quite often use database specific attributes here, that are specified in the DSN. I recommend you parse the DSN within the connect method and pass them as handle attributes to dbd_db_login. Here's how you fetch them, as an example we use hostname and port attributes:

  /* This code assumes that the *second* attribute parameter to
   * DBI::_new_dbh was used to store an hash with login attributes
   */
  SV* imp_data = DBIc_IMP_DATA(dbh);
  HV* hv;
  SV** svp;
  char* hostname;
  char* port;

  if (! SvTRUE(imp_data) || !SvROK(imp_data)  ||
        SvTYPE(hv = (HV*) SvRV(imp_data)) != SVt_PVHV) {
      croak("Implementation dependent data invalid: Not a hash ref.\n");
  }
  if ((svp = hv_fetch(hv, "hostname", strlen("hostname"), FALSE)) &&
      SvTRUE(*svp)) {
      hostname = SvPV(*svp, na);
  } else {
      hostname = "localhost";
  }
  if ((svp = hv_fetch(hv, "port", strlen("port"), FALSE)) &&
      SvTRUE(*svp)) {
      port = SvPV(*svp, na);  /*  May be a service name  */
  } else {
      port = DEFAULT_PORT;
  }

Now you should really connect to the database. If you are successful (or even if you fail, but you have allocated some resources), you should use the following macros:

  DBIc_IMPSET_on(imp_dbh);

This indicates that the driver (implementor) has allocated resources in the imp_dbh structure and that the implementors private dbd_db_destroy function should be called when the handle is destroyed.

  DBIc_ACTIVE_on(imp_dbh);

This indicates that the handle has an active connection to the server and that the dbd_db_disconnect function should be called before the handle is destroyed.

The dbd_db_login function should return TRUE for success, FALSE otherwise.

dbd_db_commit

dbd_db_rollback

  int dbd_db_commit(   SV* dbh, imp_dbh_t* imp_dbh );
  int dbd_db_rollback( SV* dbh, imp_dbh_t* imp_dbh );

These are used for commit and rollback. They should return TRUE for success, FALSE for error.

The arguments dbh and imp_dbh are like above, I will omit describing them in what follows, as they appear always.

dbd_db_disconnect

This is your private part of the disconnect method. Any dbh with the ACTIVE flag on must be disconnected. (Note that you have to set it in dbd_db_connect above.)

  int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);

The database handle will return TRUE for success, FALSE otherwise. In any case it should do a

  DBIc_ACTIVE_off(imp_dbh);

before returning so DBI knows that dbd_db_disconnect was executed.

dbd_db_discon_all

  int dbd_discon_all (SV *drh, imp_drh_t *imp_drh);

This function may be called at shutdown time. It should make best-efforts to disconnect all database handles - if possible. Some databases don't support that, in which case you can do nothing but return 'success'.

You guess what the return codes are? (Hint: See the last functions above ... :-)

dbd_db_destroy

This is your private part of the database handle destructor. Any dbh with the IMPSET flag on must be destroyed, so that you can safely free resources. (Note that you have to set it in dbd_db_connect above.)

  void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh)
  {
      DBIc_IMPSET_off(imp_dbh);
  }

The DBI Driver.xst code will have called dbd_db_disconnect for you, if the handle is still 'active', before calling dbd_db_destroy.

Before returning the function must switch IMPSET to off, so DBI knows that the destructor was called.

dbd_db_STORE_attrib

This function handles

  $dbh->{$key} = $value;

its prototype is

  int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
                          SV* valuesv);

You do not handle all attributes, in contrary you should not handle DBI attributes here: Leave this to DBI. (There's one exception, AutoCommit, which you should care about.)

The return value is TRUE, if you have handled the attribute or FALSE otherwise. If you are handling an attribute and something fails, you should call do_error, so DBI can raise exceptions, if desired. If do_error returns, however, you have a problem: The user will never know about the error, because he typically will not check "$dbh->errstr".

I cannot recommend a general way of going on, if do_error returns, but there are examples where even the DBI specification expects that you croak(). (See the AutoCommit method in DBI(3).)

If you have to store attributes, you should either use your private data structure imp_xxx, the handle hash (via (HV*)SvRV(dbh)), or use the private imp_data.

The first is best for internal C values like integers or pointers and where speed is important within the driver. The handle hash is best for values the user may want to get/set via driver-specific attributes. The private imp_data is an additional SV attached to the handle. You could think of it as an unnamed handle attribute. It's not normally used.

dbd_db_FETCH_attrib

This is the counterpart of dbd_db_STORE_attrib, needed for

  $value = $dbh->{$key};

Its prototype is:

  SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv);

Unlike all previous methods this returns an SV with the value. Note that you should normally execute sv_2mortal, if you return a nonconstant value. (Constant values are &sv_undef, &sv_no and &sv_yes.)

Note, that DBI implements a caching algorithm for attribute values. If you think, that an attribute may be fetched, you store it in the dbh itself:

  if (cacheit) /* cache value for later DBI 'quick' fetch? */
      hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);

dbd_st_prepare

This is the private part of the prepare method. Note that you must not really execute the statement here. You may, for example, preparse and validate the statement or do similar things.

  int dbd_st_prepare(SV* sth, imp_sth_t* imp_sth, char* statement,
                     SV* attribs);

A typical, simple possibility is just to store the statement in the imp_data hash ref and use it in dbd_st_execute. If you can, you should setup attributes like NUM_OF_FIELDS, NAME, ... here, but DBI doesn't require that. However, if you do, document it.

In any case you should set the IMPSET flag, as you did in dbd_db_connect above:

  DBIc_IMPSET_on(imp_sth);

dbd_st_execute

This is where a statement will really be executed.

  int dbd_st_execute(SV* sth, imp_sth_t* imp_sth);

Note, that you must be aware, that a statement may be executed repeatedly. Also, you should not expect, that finish will be called between two executions.

If your driver supports binding of parameters (he should!), but the database doesn't, you must probably do it here. This can be done as follows:

  char* statement = dbd_st_get_statement(sth, imp_sth);
      /* Its your drivers task to implement this function.  It     */
      /* must restore the statement passed to preparse.            */
      /* See use of imp_data above for an example of how to do     */
      /* this.                                                     */
  int numParam = DBIc_NUM_PARAMS(imp_sth);
  int i;

  for (i = 0; i < numParam; i++) {
      char* value = dbd_db_get_param(sth, imp_sth, i);
      /* Its your drivers task to implement dbd_db_get_param,      */
      /* it must be setup as a counterpart of dbd_bind_ph.         */
      /* Look for '?' and replace it with 'value'.  Difficult      */
      /* task, note that you may have question marks inside        */
      /* quotes and the like ...  :-(                              */
      /* See DBD::mysql for an example. (Don't look too deep into  */
      /* the example, you will notice where I was lazy ...)        */
  }

The next thing is you really execute the statement. Note that you must prepare the attributes NUM_OF_FIELDS, NAME, ... when the statement is successfully executed if you have not already done so: They may be used even before a potential fetchrow. In particular you have to tell DBI the number of fields, that the statement has, because it will be used by DBI internally. Thus the function will typically ends with:

  if (isSelectStatement) {
      DBIc_NUM_FIELDS(imp_sth) = numFields;
      DBIc_ACTIVE_on(imp_sth);
  }

It is important that the ACTIVE flag only be set for select statements. See dbd_st_preparse and dbd_db_connect above for more explanations.

dbd_st_fetch

This function fetches a row of data. The row is stored in in an array, of SV's that DBI prepares for you. This has two advantages: It is fast (you even reuse the SV's, so they don't have to be created after the first fetchrow) and it guarantees, that DBI handles bind_cols for you.

What you do is the following:

  AV* av;
  int numFields = DBIc_NUM_FIELDS(imp_sth); /* Correct, if NUM_FIELDS
      is constant for this statement. There are drivers where this is
      not the case! */
  int chopBlanks = DBIc_is(imp_sth, DBIcf_ChopBlanks);
  int i;

  if (!fetch_new_row_of_data(...)) {
      ... /* check for error or end-of-data */
      DBIc_ACTIVE_off(imp_sth); /* turn off Active flag automatically */
      return Nullav;
  }
  /* get the fbav (field buffer array value) for this row       */
  /* it is very important to only call this after you know      */
  /* that you have a row of data to return.                     */
  av = DBIS->get_fbav(imp_sth);
  for (i = 0; i < numFields; i++) {
      SV* sv = fetch_a_field(..., i);
      if (chopBlanks && SvOK(sv) && type_is_blank_padded(field_type[i])) {
          /*  Remove white space from end (only) of sv  */
      }
      sv_setsv(AvARRAY(av)[i], sv); /* Note: (re)use! */
  }
  return av;

There's no need to use a fetch_a_field function returning an SV*. It's more common to use your database API functions to fetch the data as character strings and use code like this:

  sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);

NULL values must be returned as undef. You can use code like this:

  SvOK_off(AvARRAY(av)[i]);

The function returns the AV prepared by DBI for success or "Nullav" otherwise.

dbd_st_finish

This function can be called if the user wishes to indicate that no more rows will be fetched even if the server has more rows to offer. See the DBI docs for more background details.

All it needs to do is turn off the Active flag for the sth. It will only be called by Driver.xst code, if the driver has set ACTIVE to on for the sth.

Minimal example (the DBI default method just does this):

  int dbd_st_finish(SV* sth, imp_sth_t* imp_sth) {
      DBIc_ACTIVE_off(imp_sth);
      return 1;
  }

The function returns TRUE for success, FALSE otherwise.

dbd_st_destroy

This function is the private part of the statement handle destructor.

  void dbd_st_destroy(SV* sth, imp_sth_t* imp_sth) {
      ... /* any clean-up that's needed */
      DBIc_IMPSET_off(imp_sth); /* let DBI know we've done it   */
  }

The DBI Driver.xst code will call dbd_st_finish for you, if the sth has the ACTIVE flag set, before calling dbd_st_destroy.

dbd_st_STORE_attrib

dbd_st_FETCH_attrib

These functions correspond to dbd_db_STORE|FETCH attrib above, except that they are for statement handles. See above.

  int dbd_st_STORE_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv,
                          SV* valuesv);
  SV* dbd_st_FETCH_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv);

dbd_bind_ph

This function is internally used by the bind_param method, the bind_param_inout method and by the DBI Driver.xst code if "execute" is called with any bind parameters.

  int dbd_bind_ph (SV *sth, imp_sth_t *imp_sth, SV *param,
                   SV *value, IV sql_type, SV *attribs,
                   int is_inout, IV maxlen);

The param argument holds an IV with the parameter number (1, 2, ...). The value argument is the parameter value and sql_type is its type.

If your driver does not support bind_param_inout then you should ignore maxlen and croak if is_inout is TRUE.

If your driver does support bind_param_inout then you should note that value is the SV after dereferencing the reference passed to bind_param_inout.

In drivers of simple databases the function will, for example, store the value in a parameter array and use it later in dbd_st_execute. See the DBD::mysql driver for an example.

Implementing bind_param_inout support

  $sth->execute;

  $sth->execute(@values);

Makefile.PL

METHODS WHICH DO NOT NEED TO BE WRITTEN

The DBI code implements the following documented driver, database and statement functions which do not need to be written by the DBD driver writer.

$dbh->do()

The default implementation of this function prepares, executes and destroys the statement. This can be replaced if there is a better way to implement this, such as EXECUTE IMMEDIATE which can sometimes be used if there are no parameters.

$h->errstr()

$h->err()

$h->state()

$h->trace()

The DBD driver does not need to worry about these routines at all.

$h->{ChopBlanks}

This attribute needs to be honured during fetch operations, but does not need to be handled by the attribute handling code.

$h->{RaiseError}

The DBD driver does not need to worry about this attribute at all.

$h->{PrintError}

The DBD driver does not need to worry about this attribute at all.

$sth->bind_col()

Assuming the driver uses the DBIS->get_fbav() function (C drivers, see below), or the $sth->_set_fbav($data) method (Perl drivers) the driver does not need to do anything about this routine.

$sth->bind_columns()

Regardless of whether the driver uses DBIS->get_fbav(), the driver does not need to do anything about this routine as it simply iteratively calls $sth->bind_col().

The DBI code implements a default implementation of the following functions which do not need to be written by the DBD driver writer unless the default implementation is incorrect for the Driver.

$dbh->quote()

This should only be written if the database does not accept the ANSI SQL standard for quoting strings, with the string enclosed in single quotes and any embedded single quotes replaced by two consecutive single quotes.

For the two argument form of quote, you need to implement the "type_info" method to provide the information that quote needs.

$dbh->ping()

This should be implemented as a simple efficient way to determine whether the connection to the database is still alive. Typically code like this:

  sub ping {
      my $dbh = shift;
      $sth = $dbh->prepare_cached(q{
          select * from A_TABLE_NAME where 1=0
      }) or return 0;
      $sth->execute or return 0;
      $sth->finish;
      return 1;
  }

where A_TABLE_NAME is the name of a table that always exists (such as a database system catalogue).

WRITING AN EMULATION LAYER FOR AN OLD PERL INTERFACE

Note that the emulation code sets $dbh->{CompatMode} = 1; for each connection so that the internals of the driver can implement behaviour compatible with the old interface when dealing with those handles.  

Setting emulation perl variables

  sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);

  if (DBIc_COMPAT(imp_sth))     /* only do this for compatibility mode handles */
      sv_setiv(sql_rowcount, the_row_count);

OTHER MISCELLANEOUS INFORMATION

The imp_xyz_t types

D_imp_dbh(dbh)

Given a function argument dbh, declare a variable imp_dbh and initialize it with a pointer to the handles private data. Note: This must be a part of the function header, because it declares a variable.

D_imp_sth(sth)

Likewise for statement handles.

D_imp_xxx(h)

Given any handle, declare a variable imp_xxx and initialize it with a pointer to the handles private data. It is safe, for example, to cast imp_xxx to "imp_dbh_t*", if DBIc_TYPE(imp_xxx) == DBIt_DB. (You can also call sv_derived_from(h, ``DBI::db''), but that's much slower.)

D_imp_sth_from_dbh

Given a imp_sth, declare a variable imp_dbh and initialize it with a pointer to the parent database handles implementors structure.

Using DBIc_IMPSET_on

Failure to call this can lead to corruption of data structures. For example, DBD::Informix maintains a linked list of database handles in the driver, and within each handle, a linked list of statements. Once a statement is added to the linked list, it is crucial that it is cleaned up (removed from the list). When DBIc_IMPSET_on() was being called too late, it was able to cause all sorts of problems.  

Using DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off()

  DBIc_WARN       DBIc_WARN_on        DBIc_WARN_off
  DBIc_COMPAT     DBIc_COMPAT_on      DBIc_COMPAT_off

Since then, new attributes have been added such as ChopBlanks, RaiseError and PrintError, and these do not have the full set of macros. The approved method for handling these is now the four macros:

  DBIc_is(imp, flag)
  DBIc_has(imp, flag)    an alias for DBIc_is
  DBIc_on(imp, flag)
  DBIc_off(imp, flag)

There is an important exception to that. The ACTIVE and IMPSET flags should be set via the DBIc_ACTIVE_on and DBIc_IMPSET_on macros, and unset via the DBIc_ACTIVE_off and DBIc_IMPSET_off macros.  

Using DBIS->get_fbav()

The above is for C drivers only. The Perl equivalent is the $sth->_set_fbav($data) method, as described in the part on Pure Perl drivers.  

SUBCLASSING DBI DRIVERS

(Note that this topic is different from subclassing the DBI. For an example of that, see the t/subclass.t file supplied with the DBI.)

The main problem is that the dbh's and sth's that your connect and prepare methods return are not instances of your DBD::Driver::db or DBD::Driver::st packages, they are not even derived from it. Instead they are instances of the DBI::db or DBI::st classes or a derived subclass. Thus, if you write a method mymethod and do a

  $dbh->mymethod()

  $dbh->func('mymethod')

Overwriting methods

  require DBD::Driver;

Of course that's not much of a problem. You should even be able to inherit the base classes connect method. But you cannot simply overwrite the method, unless you do something like this, quoted from DBD::CSV:

  sub connect ($$;$$$) {
      my ($drh, $dbname, $user, $auth, $attr) = @_;

      my $this = $drh->DBD::File::dr::connect($dbname, $user, $auth, $attr);
      if (!exists($this->{csv_tables})) {
          $this->{csv_tables} = {};
      }

      $this;
  }

  $srh->SUPER::connect($dbname, $user, $auth, $attr);

It is essential that you always call superclass method in the above manner. However, that should do.  

Attribute handling

  sub STORE {
      my ($dbh, $attr, $val) = @_;
      if ($attr !~ /^driver_/) {
          return $dbh->DBD::File::db::STORE($attr, $val);
      }
      if ($attr eq 'driver_foo') {
      ...
  }

ACKNOWLEDGEMENTS

AUTHORS

Index

NAME

SYNOPSIS

VERSION and VOLATILITY

DESCRIPTION

BOOK

REGISTERING A NEW DRIVER

Locating drivers

Registering a new driver

CREATING A NEW DRIVER USING PURE PERL

Makefile.PL

README file

MANIFEST

lib/Bundle/DBD/Driver.pm

Driver.pm

Tests

CREATING A NEW DRIVER USING C/XS

REQUIREMENTS ON A DRIVER

CODE TO BE WRITTEN

Driver.pm

Driver.xs

Driver.h

Implementation header dbdimp.h

Implementation source dbdimp.c

Implementing bind_param_inout support

Makefile.PL

METHODS WHICH DO NOT NEED TO BE WRITTEN

WRITING AN EMULATION LAYER FOR AN OLD PERL INTERFACE

Setting emulation perl variables

OTHER MISCELLANEOUS INFORMATION

The imp_xyz_t types

Using DBIc_IMPSET_on

Using DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off()

Using DBIS->get_fbav()

SUBCLASSING DBI DRIVERS

Overwriting methods

Attribute handling

ACKNOWLEDGEMENTS

AUTHORS