.\" Automatically generated by Pod::Man v1.34, Pod::Parser v1.13
.\" ========================================================================
.de Sh \" Subsection heading
.de Sp \" Vertical space (when we can't use .PP)
.de Vb \" Begin verbatim text
.de Ve \" End verbatim text
.\" Set up some character translations and predefined strings. \*(-- will
.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
.\" double quote, and \*(R" will give a right double quote. | will give a
.\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to
.\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C'
.\" expand to `' in nroff, nothing in troff, for use with C<>.
.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
. if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
. if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch
.\" If the F register is turned on, we'll generate index entries on stderr for
.\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index
.\" entries marked with X<> in POD. Of course, you'll have to process the
.\" output yourself in some meaningful fashion.
. tm Index:\\$1\t\\n%\t"\\$2"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
.\" Fear. Run. Save yourself. No user-serviceable parts.
. \" fudge factors for nroff and troff
. ds #H ((1u-(\\\\n(.fu%2u))*.13m)
. \" simple accents for nroff and troff
. ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
. ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
. ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
. ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
. ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
. ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
. \" troff and (daisy-wheel) nroff accents
.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
.ds ae a\h'-(\w'a'u*4/10)'e
.ds Ae A\h'-(\w'A'u*4/10)'E
. \" corrections for vroff
.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
. \" for low resolution devices (crt and lpr)
.if \n(.H>23 .if \n(.V>19 \
.\" ========================================================================
.TH DBI::DBD 3 "2002-10-01" "perl v5.8.0" "User Contributed Perl Documentation"
DBI::DBD \- DBD Driver Writer's Guide
.SH "VERSION and VOLATILITY"
.IX Header "VERSION and VOLATILITY"
\& $Date: 2001/05/29 23:25:55 $
This document is a minimal draft which is in need of further work.
The changes will occur both because the \s-1DBI\s0 specification is changing
and hence the requirements on \s-1DBD\s0 drivers change, and because feedback
from people reading this document will suggest improvements to it.
Please read the \s-1DBI\s0 documentation first and fully, including the \s-1DBI\s0 \s-1FAQ\s0.
The reread the \s-1DBI\s0 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.
This document is primarily intended to help people writing new
database drivers for the Perl Database Interface (Perl \s-1DBI\s0).
It may also help others interested in discovering why the internals of
a \s-1DBD\s0 driver are written the way they are.
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 \fIany\fR 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 \s-1DBI\s0 software and information is
\& http://www.symbolstone.org/technology/perl/DBI
There are 2 main and one auxilliary mailing lists for people working
with \s-1DBI\s0. The primary lists are dbi\-users@isc.org for general users
of \s-1DBI\s0 and \s-1DBD\s0 drivers, and dbi\-dev@isc.org mainly for \s-1DBD\s0 driver
writers (don't join the dbi-dev list unless you have a good reason).
The auxilliary list is dbi\-announce@isc.org for announcing new
releases of \s-1DBI\s0 or \s-1DBD\s0 drivers.
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.
The definitive book on Perl \s-1DBI\s0 is 'Programming the Perl \s-1DBI:\s0 Database
programming with Perl' by Alligator Descartes and Tim Bunce, published
by O'Reilly Associates, February 2000, \s-1ISBN\s0 1\-56592\-699\-4. Buy it now
if you have not already done so.
.SH "REGISTERING A NEW DRIVER"
.IX Header "REGISTERING A NEW DRIVER"
Before writing a new driver, it is in your interests to find out
whether there already is a driver for your database. If there is such
a driver, it would be much easier to make use of it than to write your
.IX Subsection "Locating drivers"
The primary web-site for locating Perl software is
<http://www.perl.com/CPAN>.
You should look under the various modules listings for the software
Two of the main pages you should look at are:
\& http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces/DBI
\& http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces/DBD
See the \s-1DBI\s0 docs for information on \s-1DBI\s0 web sites and mailing lists.
.Sh "Registering a new driver"
.IX Subsection "Registering a new driver"
Before going through any official registration process, you will need
to establish that there is no driver already in the works.
You'll do that by asking the \s-1DBI\s0 mailing lists whether there is such a
driver available, or whether anybody is working on one.
.SH "CREATING A NEW DRIVER USING PURE PERL"
.IX Header "CREATING A NEW DRIVER USING PURE PERL"
Writing a pure Perl driver is surprisingly simple. However, there are
some problems one should be aware of. The best option is of course
picking up an existing driver and carefully modifying one method
As an example we take a look at the \fIDBD::File\fR driver, a driver for
accessing plain files as tables, which is part of the \fI\s-1DBD::CSV\s0\fR
package. In what follows I assume the name \f(CW\*(C`Driver\*(C'\fR for your new
package: The least thing we have to implement are the files
\&\f(CW\*(C`Makefile.PL\*(C'\fR and \f(CW\*(C`Driver.pm\*(C'\fR.
.IX Subsection "Makefile.PL"
You typically start with writing \f(CW\*(C`Makefile.PL\*(C'\fR, a Makefile generator.
The contents of this file are described in detail in the MakeMaker
man pages, it's definitely a good idea if you start reading them.
At least you should know about the variables \fI\s-1CONFIGURE\s0\fR, \fI\s-1DEFINED\s0\fR,
\&\fI\s-1DIR\s0\fR, \fI\s-1EXE_FILES\s0\fR, \fI\s-1INC\s0\fR, \fI\s-1LIBS\s0\fR, \fI\s-1LINKTYPE\s0\fR, \fI\s-1NAME\s0\fR, \fI\s-1OPTIMIZE\s0\fR,
\&\fI\s-1PL_FILES\s0\fR, \fI\s-1VERSION\s0\fR, \fI\s-1VERSION_FROM\s0\fR, \fIclean\fR, \fIdepend\fR, \fIrealclean\fR
from the \f(CW\*(C`ExtUtils::MakeMaker\*(C'\fR man page: These are used in almost any
Makefile.PL. Additionally read the section on \fIOverriding MakeMaker Methods\fR
and the descriptions of the \fIdistcheck\fR, \fIdisttest\fR and \fIdist\fR targets:
They will definitely be useful for you.
Of special importance for \s-1DBI\s0 drivers is the \fIpostamble\fR method from
the \f(CW\*(C`ExtUtils::MM_Unix\*(C'\fR man page. And for Emacs users I recommend
the \fIlibscan\fR method.
Now an example, I use the word \f(CW\*(C`Driver\*(C'\fR wherever you should insert
\& 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'
\& sub postamble { dbd_postamble(@_); }
\& my($self, $path) = @_;
\& ($path =~ /\e~$/) ? undef : $path;
See also \fIExtUtils::MakeMaker\fR\|(3). \fIExtUtils::MM_Unix\fR\|(3).
.IX Subsection "README file"
The \s-1README\s0 file should describe what the driver is for, the
pre-requisites for the build process, the actual build process, and how
to report errors. Users will find ways of breaking the driver build and
test process which you would never even dreamed to be possible in your
nightmares. :\-) Therefore, you need to write this document defensively
and precisely. Also, it is in your interests to ensure that your tests
work as widely as possible. As always, use the \s-1README\s0 from one of the
established drivers as a basis for your own.
.IX Subsection "MANIFEST"
The \s-1MANIFEST\s0 will be used by the Makefile'd dist target to build the
distribution tar file that is uploaded to \s-1CPAN\s0. It should list every
file that you want to include in your distribution, one per line.
.Sh "lib/Bundle/DBD/Driver.pm"
.IX Subsection "lib/Bundle/DBD/Driver.pm"
The \s-1CPAN\s0 module provides an extremely powerful bundle mechanism that
allows you to specify pre-requisites for your driver.
The primary pre-requisite is Bundle::DBI; you may want or need to add
With the bundle set up correctly, the user can type:
\& perl -MCPAN -e 'install Bundle::DBD::Driver'
and Perl will download, compile, test and install all the Perl modules
needed to build your driver.
A suitable skeleton for this file is shown below.
The prerequisite modules are listed in the \s-1CONTENTS\s0 section, with the
official name of the module followed by a dash and an informal name or
Listing Bundle::DBI as the main pre-requisite simplifies life.
Don't forget to list your driver.
Note that unless the \s-1DBMS\s0 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;
\& Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules
\& C<perl -MCPAN -e 'install Bundle::DBD::Driver'>
\& Bundle::DBI - Bundle for DBI by TIMB (Tim Bunce)
\& DBD::Driver - DBD::Driver by YOU (Your Name)
\& 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'>
\& Your Name E<lt>F<you@yourdomain.com>E<gt>
\& 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>.
.IX Subsection "Driver.pm"
The Driver.pm file defines the Perl module DBD::Driver for your driver.
It will define a package DBD::Driver along with some version information,
some variable definitions, and a function \fIdriver()\fR which will have a more
or less standard structure.
It will also define a package DBD::Driver::dr (with methods \fIconnect()\fR,
\&\fIdata_sources()\fR and \fIdisconnect_all()\fR), and a package DBD::Driver::db
(which will define a function \fIprepare()\fR etc), and a package DBD::Driver::st
with methods \fIexecute()\fR, \fIfetch()\fR 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.
\& 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 \fIevent\fR 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.
.IP "The driver constructor" 2
.IX Item "The driver constructor"
\& return $drh if $drh; # already created - return same one
\& my($class, $attr) = @_;
\& # not a 'my' since we use it above to prevent multiple drivers
\& $drh = DBI::_new_drh($class, {
\& 'Version' => $VERSION,
\& 'Err' => \e$DBD::File::err,
\& 'Errstr' => \e$DBD::File::errstr,
\& 'State' => \e$DBD::File::state,
\& 'Attribution' => 'DBD::File by Jochen Wiedmann',
The \fIdriver\fR method is the driver handle constructor. It's a
reasonable example of how \s-1DBI\s0 implements its handles. There are three
kinds: \fBdriver handles\fR (typically stored in \f(CW$drh\fR, from now on
called \f(CW\*(C`drh\*(C'\fR), \fBdatabase handles\fR (from now on called \f(CW\*(C`dbh\*(C'\fR or
\&\f(CW$dbh\fR) and \fBstatement handles\fR, (from now on called \f(CW\*(C`sth\*(C'\fR or
The prototype of DBI::_new_drh is
\& $drh = DBI::_new_drh($class, $attr1, $attr2);
with the following arguments:
is typically your drivers class, e.g., \*(L"DBD::File::dr\*(R", passed as first
argument to the \fIdriver\fR method.
is a hash ref to attributes like \fIName\fR, \fIVersion\fR, \fIErr\fR, \fIErrstr\fR
\&\fIState\fR and \fIAttributrion\fR. These are processed and used by \s-1DBI\s0, you
better not make any assumptions on them nor should you add private
This is another (optional) hash ref with your private attributes. \s-1DBI\s0
The \fIDBI::new_drh\fR method and the \fIdriver\fR method
both return \f(CW\*(C`undef\*(C'\fR for failure (in which case you must look at
\&\f(CW$DBI::err\fR and \f(CW$DBI::errstr\fR, because you have no driver handle).
.IP "The database handle constructor" 2
.IX Item "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 \f(CW@ISA\fR is needed here, or for the other DBD::Driver::*
classes, because the \s-1DBI\s0 takes care of that for you when the driver is
The database handle constructor is a driver method, thus we have
\& 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, {
\& 'CURRENT_USER' => $user,
\& # Process attributes from the DSN; we assume ODBC syntax
\& # here, that is, the DSN looks like var1=val1;...;varN=valN
\& foreach $var (split(/;/, $dbname)) {
\& if ($var =~ /(.*?)=(,*)/) {
\& # Not !!! $dbh->{$var} = $val;
\& $dbh->STORE($var, $val);
This is mostly the same as in the \fIdriver handle constructor\fR above.
The arguments are described in the \s-1DBI\s0 man page. See \s-1\fIDBI\s0\fR\|(3).
The constructor is called, returning a database handle. The constructors
\& $dbh = DBI::_new_dbh($drh, $attr1, $attr2);
with the same arguments as in the \fIdriver handle constructor\fR, the
exception being \f(CW$class\fR replaced by \f(CW$drh\fR.
Note the use of the \fI\s-1STORE\s0\fR 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
However, some attribute values, such as those handled by the \s-1DBI\s0
like PrintError, don't actually exist in the hash and must be
read via \f(CW$h\fR\->\s-1FETCH\s0($attrib) and set via \f(CW$h\fR\->\s-1STORE\s0($attrib, \f(CW$value\fR).
If in any doubt, use these methods.
.IX Item "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
To report an error, you use the \f(CW\*(C`DBI::set_err\*(C'\fR 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 ...;
.IP "Other driver handle methods" 2
.IX Item "Other driver handle methods"
may follow here. In particular you should consider a \fIdata_sources\fR
method, and a (possibly empty) \fIdisconnect_all\fR method. See \s-1\fIDBI\s0\fR\|(3).
.IP "The statement handle constructor" 2
.IX Item "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;
\& 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/?//));
This is still the same: Check the arguments and call the super class
constructor \fIDBI::_new_sth\fR. Note the prefix \fIdriver_\fR in the
attribute names: It is required that your private attributes
are lowercased and use such a prefix. See the \s-1DBI\s0 manual.
Note that we parse the statement here in order to setup the attribute
\&\fI\s-1NUM_OF_PARAMS\s0\fR. We could as well do this in the \fIexecute\fR method
below, the \s-1DBI\s0 specs explicitly allow to defer this. However, one
could not call \fIbind_param\fR in that case.
.IP "Transaction handling" 2
.IX Item "Transaction handling"
Pure Perl drivers will rarely support transactions. Thus you're \fIcommit\fR
and \fIrollback\fR methods will typically be quite simple:
\& if ($dbh->FETCH('Warn')) {
\& warn("Commit ineffective while AutoCommit is on");
\& if ($dbh->FETCH('Warn')) {
\& warn("Rollback ineffective while AutoCommit is on");
.IP "The \s-1STORE\s0 and \s-1FETCH\s0 methods" 2
.IX Item "The STORE and FETCH methods"
These methods (that we have already used, see above) are called for
you, whenever the user does a
See \fIperltie\fR\|(1) for details on tied hash refs to understand why these
The \s-1DBI\s0 will handle most attributes for you, in particular attributes
like \fIRaiseError\fR or \fIPrintError\fR. All you have to do handle your
driver's private attributes and any attributes, like AutoCommit, that
the \s-1DBI\s0 can't handle for you. A good example might look like this:
\& my($dbh, $attr, $val) = @_;
\& if ($attr eq 'AutoCommit') {
\& # AutoCommit is currently the only standard attribute we have
\& if (!$val) { die "Can't disable AutoCommit"; }
\& if ($attr =~ /^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);
\& if ($attr eq 'AutoCommit') { return 1; }
\& if ($attr =~ /^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 \s-1DBI\s0 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 \s-1FETCH\s0 and \s-1STORE\s0 methods unless
you need extra logic/checks, beyond getting or setting the value.
.IP "Other database handle methods" 2
.IX Item "Other database handle methods"
may follow here. In particular you should consider a (possibly empty)
\&\fIdisconnect\fR method, a \fIquote\fR method (if \s-1DBI\s0's default isn't good
.IP "The execute method" 2
.IX Item "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 \fIdriver_params\fR attribute from above:
\& package DBD::Driver::st;
\& $DBD::Driver::st::imp_data_size = 0;
\& my($sth, $pNum, $val, $attr) = @_;
\& my $type = (ref $attr) ? $attr->{TYPE} : $attr;
\& my $dbh = $sth->{Database};
\& $val = $dbh->quote($sth, $type);
\& my $params = $sth->FETCH('driver_params');
\& $params->[$pNum-1] = $val;
\& my($sth, @bind_values) = @_;
\& my $params = (@bind_values) ?
\& \e@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;
Things you should note here: We setup the \s-1NUM_OF_FIELDS\s0 attribute
here, because this is essential for \fIbind_columns\fR to work. And
we use attribute \fI$sth\-\fR{'Statement'}> which we have created
within \fIprepare\fR. The attribute \fI$sth\-\fR{'Database'}>, which is
nothing else than the \fIdbh\fR, was automatically created by \s-1DBI\s0.
Finally note that we return the string '0E0' instead of the number
\& if (!$sth->execute()) { die $sth->errstr }
We need not implement the methods \fIfetchrow_array\fR, \fIfetchall_arrayref\fR,
\&... because these are already part of \s-1DBI\s0. All we need is the method
\&\fIfetchrow_arrayref\fR:
\& sub fetchrow_arrayref {
\& my $data = $sth->FETCH('driver_data');
\& my $row = shift @$data;
\& if (!$row) { return undef; }
\& if ($sth->FETCH('ChopBlanks')) {
\& map { $_ =~ s/\es+$//; } @$row;
\& return $sth->_set_fbav($row);
\& *fetch = \e&fetchrow_arrayref; # required alias for fetchrow_arrayref
\& sub rows { my($sth) = @_; $sth->FETCH('driver_rows'); }
Note the use of the method \fI_set_fbav\fR: This is required so that
\&\fIbind_col\fR and \fIbind_columns\fR work.
Fixing the broken implementation for correct handling of quoted
question marks is left as an exercise to the reader. :\-)
.IP "Statement attributes" 2
.IX Item "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 \s-1DBI:\s0 For example \fI\s-1NAME\s0\fR, \fI\s-1NULLABLE\s0\fR, \fI\s-1TYPE\s0\fR, ...
Besides that the \s-1STORE\s0 and \s-1FETCH\s0 methods are mainly the same
.IP "Other statement methods" 2
.IX Item "Other statement methods"
A trivial \f(CW\*(C`finish\*(C'\fR method to discard the stored data and do
\&\f(CW$sth\fR\->SUPER::finish;
A \f(CW\*(C`table_info\*(C'\fR method to return details of available tables.
A \f(CW\*(C`type_info_all\*(C'\fR method to return details of supported types.
And perhaps some other methods that are not part of the \s-1DBI\s0 specs, in
particular make metadata available. Considering Tim's last articles do
yourself a favour and follow the \s-1ODBC\s0 driver.
The test process should conform as closely as possibly to the Perl
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, \*(L"The Standard Perl Library\*(R" 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
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.
.SH "CREATING A NEW DRIVER USING C/XS"
.IX Header "CREATING A NEW DRIVER USING C/XS"
Creating a new C/XS driver from scratch will always be a daunting task.
You can and should greatly simplify your task by taking a good
reference driver implementation and modifying that to match the
database product for which you are writing a driver.
The de facto reference driver has been the one for DBD::Oracle, written
by Tim Bunce who is also the author of the \s-1DBI\s0 package. The DBD::Oracle
module is a good example of a driver implemented around a C\-level \s-1API\s0.
Nowadays it it seems better to base on \s-1DBD::ODBC\s0, 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 \s-1OCI\s0 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 \s-1SQL\s0'. DBD::Ingres may also be worth a look.
.Sh "\s-1REQUIREMENTS\s0 \s-1ON\s0 A \s-1DRIVER\s0"
.IX Subsection "REQUIREMENTS ON A DRIVER"
.Sh "\s-1CODE\s0 \s-1TO\s0 \s-1BE\s0 \s-1WRITTEN\s0"
.IX Subsection "CODE TO BE WRITTEN"
A minimal driver will typically contain 9 files plus some tests.
Assuming that your driver is called DBD::Driver, these files are:
.IP "lib/Bundle/DBD/Driver.pm" 4
.IX Item "lib/Bundle/DBD/Driver.pm"
.IX Subsection "Driver.pm"
The Driver.pm file is the same as for Pure Perl modules, see above.
However, there are some subtile differences:
The variables \f(CW$DBD::File::dr\fR|db|st::imp_data_size are not defined
here, but in the \s-1XS\s0 code, because they declare the size of certain
Some methods are typically moved to the \s-1XS\s0 code, in particular
\&\fIprepare\fR, \fIexecute\fR, \fIdisconnect\fR, \fIdisconnect_all\fR and the \s-1STORE\s0
and \s-1FETCH\s0 methods.
Other methods are still part of \f(CW\*(C`Driver.pm\*(C'\fR, but have callbacks in
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.
.IP "The database handle constructor" 2
.IX Item "The database handle constructor"
\& 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, {
\& '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)
This is mostly the same as in the Pure Perl case, the exception being
the use of the private \fI_login\fR callback: This will really connect to
the database. It is implemented in Driver.xst (you should not implement
it) and calls \fIdbd_db_login\fR from \fIdbdimp.c\fR. See below for details.
Since the DBI::_new_xxh methods can't fail in normal situations, we
don't both checking \f(CW$dbh\fR before calling _login.
.IP "The statement handle constructor" 2
.IX Item "The statement handle constructor"
There's nothing much new in the statement handle constructor. Like
the \fIconnect\fR method it now has a C callback:
\& package DBD::Oracle::db; # ====== DATABASE ======
\& 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)
.IX Subsection "Driver.xs"
Driver.xs should look something like this:
\& 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. */
Note especially the include of \fIDriver.xsi\fR here: \s-1DBI\s0 inserts stub
functions for almost all private methods here which will typically
do much work for you. Wherever you really have to implement something,
it will call a private function in \fIdbdimp.c\fR: This is what you have
.IX Subsection "Driver.h"
Driver.h should look like this:
\& #define NEED_DBIXS_VERSION 93
\& #include <DBIXS.h> /* installed by the DBI module */
\& #include <dbd_xsh.h> /* installed by the DBI module */
.Sh "Implementation header dbdimp.h"
.IX Subsection "Implementation header dbdimp.h"
This header file has two jobs:
First it defines data structures for your private part of the handles.
Second it defines macros that rename the generic names like
\&\fIdbd_db_login\fR to database specific names like \fIora_db_login\fR. 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 \s-1XS\s0 methods that you
Finally, the macros will also be used to select alternate
implementations of some functions. For example, the currently defined
\&\f(CW\*(C`dbd_db_login\*(C'\fR 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
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 \s-1DBI\s0 specific parts, Oracle
specific parts, mSQL specific parts and mysql specific parts in
DBD::mysql's \fIdbdimp.h\fR and \fIdbdimp.c\fR. (DBD::mysql was a port of
DBD::mSQL which was based on DBD::Oracle.) This part of the driver
is \fIyour exclusive part\fR. 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.)
\& dbih_drc_t com; /* MUST be first element in structure */
\& /* Insert your driver handle attributes here */
\& dbih_dbc_t com; /* MUST be first element in structure */
\& /* Insert your database handle attributes here */
\& dbih_stc_t com; /* MUST be first element in structure */
\& /* Insert your statement handle attributes here */
\& /* Rename functions for avoiding name clashes; prototypes are */
\& #define dbd_init ora_init
\& #define dbd_db_login ora_db_login
\& #define dbd_db_do ora_db_do
\& ... many more here ...
This structures implement your private part of the handles. You \fIhave\fR
to use the name \fIimp_dbh_dr|db|st\fR and the first field \fImust\fR be of
type \fIdbih_drc|dbc|stc_t\fR. You should never access this fields directly,
except of using the \fIDBIc_xxx\fR macros below.
.Sh "Implementation source dbdimp.c"
.IX Subsection "Implementation source dbdimp.c"
This is the main implementation file. I will drop a short note on any
function here that's used in the \fIDriver.xsi\fR template and thus \fBhas\fR
to be implemented. Of course you can add private or better static
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 \s-1ANSI\s0. Finally Tim Bunce has announced
interest in moving the \s-1DBI\s0 sources to \s-1ANSI\s0 as well.
.IX Item "Initialization"
\& 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 \s-1DBI\s0 macros. They will include your
private header file \fIdbdimp.h\fR in turn.
You need a function to handle recording of errors. You can call it
whatever you like, but we'll call it \f(CW\*(C`do_error\*(C'\fR here.
\& void do_error(SV* h, int rc, char* what) {
Note that \fIh\fR is a generic handle, may it be a driver handle, a
database or a statement handle.
This macro will declare and initialize a variable \fIimp_xxh\fR with
a pointer to your private handle pointer. You may cast this to
to \fIimp_drh_t\fR, \fIimp_dbh_t\fR or \fIimp_sth_t\fR.
\& 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 \fIRaiseError\fR
and \fIPrintError\fR work: That's all what you have to deal with them. :\-)
\& fprintf(DBILOGFP, "%s error %d recorded: %s\en",
\& what, rc, SvPV(errstr,na));
That's the first time we see how debug/trace logging works within a \s-1DBI\s0
driver. Make use of this as often as you can!
\& 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 \fIdbh\fR
is the database handle. \fIimp_dbh\fR is the pointer to the handles private
data, as is \fIimp_xxx\fR in \fIdo_error\fR above. The arguments \fIdsn\fR,
\&\fIuser\fR and \fIauth\fR correspond to the arguments of the driver handles
You will quite often use database specific attributes here, that are
specified in the \s-1DSN\s0. I recommend you parse the \s-1DSN\s0 within the
\&\fIconnect\fR method and pass them as handle attributes to \fIdbd_db_login\fR.
Here's how you fetch them, as an example we use \fIhostname\fR and \fIport\fR
\& /* 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);
\& if (!SvTRUE(imp_data) || !SvROK(imp_data) ||
\& SvTYPE(hv = (HV*) SvRV(imp_data)) != SVt_PVHV) {
\& croak("Implementation dependent data invalid: Not a hash ref.\en");
\& if ((svp = hv_fetch(hv, "hostname", strlen("hostname"), FALSE)) &&
\& hostname = SvPV(*svp, na);
\& hostname = "localhost";
\& if ((svp = hv_fetch(hv, "port", strlen("port"), FALSE)) &&
\& port = SvPV(*svp, na); /* May be a service name */
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
The dbd_db_login function should return \s-1TRUE\s0 for success, \s-1FALSE\s0 otherwise.
.IX Item "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 \s-1TRUE\s0 for
success, \s-1FALSE\s0 for error.
The arguments \fIdbh\fR and \fIimp_dbh\fR are like above, I will omit
describing them in what follows, as they appear always.
.IP "dbd_db_disconnect" 2
.IX Item "dbd_db_disconnect"
This is your private part of the \fIdisconnect\fR method. Any dbh with
the \fI\s-1ACTIVE\s0\fR flag on must be disconnected. (Note that you have to set
it in \fIdbd_db_connect\fR above.)
\& int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);
The database handle will return \s-1TRUE\s0 for success, \s-1FALSE\s0 otherwise.
In any case it should do a
\& DBIc_ACTIVE_off(imp_dbh);
before returning so \s-1DBI\s0 knows that \fIdbd_db_disconnect\fR was executed.
.IP "dbd_db_discon_all" 2
.IX Item "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
You guess what the return codes are? (Hint: See the last functions
.IX Item "dbd_db_destroy"
This is your private part of the database handle destructor. Any dbh with
the \fI\s-1IMPSET\s0\fR flag on must be destroyed, so that you can safely free
resources. (Note that you have to set it in \fIdbd_db_connect\fR above.)
\& void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh) {
\& DBIc_IMPSET_off(imp_dbh);
The \s-1DBI\s0 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 \s-1IMPSET\s0 to off, so \s-1DBI\s0 knows
that the destructor was called.
.IP "dbd_db_STORE_attrib" 2
.IX Item "dbd_db_STORE_attrib"
\& $dbh->{$key} = $value;
\& int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
You do not handle all attributes, in contrary you should not handle
\&\s-1DBI\s0 attributes here: Leave this to \s-1DBI\s0. (There's one exception,
\&\fIAutoCommit\fR, which you should care about.)
The return value is \s-1TRUE\s0, if you have handled the attribute or \s-1FALSE\s0
otherwise. If you are handling an attribute and something fails, you
should call \fIdo_error\fR, so \s-1DBI\s0 can raise exceptions, if desired.
If \fIdo_error\fR returns, however, you have a problem: The user will
never know about the error, because he typically will not check
\&\f(CW\*(C`$dbh\->errstr\*(C'\fR.
I cannot recommend a general way of going on, if \fIdo_error\fR returns,
but there are examples where even the \s-1DBI\s0 specification expects that
you \fIcroak()\fR. (See the \fIAutoCommit\fR method in \s-1\fIDBI\s0\fR\|(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 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 \s-1SV\s0 attached to the handle. You
could think of it as an unnamed handle attribute. It's not normally used.
.IP "dbd_db_FETCH_attrib" 2
.IX Item "dbd_db_FETCH_attrib"
This is the counterpart of dbd_db_STORE_attrib, needed for
\& $value = $dbh->{$key};
\& SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv) {
Unlike all previous methods this returns an \s-1SV\s0 with the value. Note
that you should normally execute sv_2mortal, if you return a nonconstant
value. (Constant values are \f(CW&sv_undef\fR, \f(CW&sv_no\fR and \f(CW&sv_yes\fR.)
Note, that \s-1DBI\s0 implements a caching algorithm for attribute values.
If you think, that an attribute may be fetched, you store it in the
\& if (cacheit) /* cache value for later DBI 'quick' fetch? */
\& hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);
.IX Item "dbd_st_prepare"
This is the private part of the \fIprepare\fR method. Note that you
\&\fBmust not\fR 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,
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 \s-1NUM_OF_FIELDS\s0, \s-1NAME\s0, ... here, but \s-1DBI\s0
doesn't require that. However, if you do, document it.
In any case you should set the \s-1IMPSET\s0 flag, as you did in
\&\fIdbd_db_connect\fR above:
\& DBIc_IMPSET_on(imp_sth);
.IX Item "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 \fIfinish\fR will be called between
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
\& 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 */
\& int numParam = DBIc_NUM_PARAMS(imp_sth);
\& 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 \s-1NUM_OF_FIELDS\s0, \s-1NAME\s0, ... when the statement is
successfully executed if you have not already done so: They may be used even before a potential
\&\fIfetchrow\fR. In particular you have to tell \s-1DBI\s0 the number of fields,
that the statement has, because it will be used by \s-1DBI\s0 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 \s-1ACTIVE\s0 flag only be set for select statements.
See \fIdbd_st_preparse\fR and \fIdbd_db_connect\fR above for more explanations.
This function fetches a row of data. The row is stored in in an array,
of \s-1SV\s0's that \s-1DBI\s0 prepares for you. This has two advantages: It is fast
(you even reuse the \s-1SV\s0's, so they don't have to be created after the
first fetchrow) and it guarantees, that \s-1DBI\s0 handles \fIbind_cols\fR for
What you do is the following:
\& int numFields = DBIc_NUM_FIELDS(imp_sth); /* Correct, if NUM_FIELDS
\& is constant for this statement. There are drivers where this is
\& int chopBlanks = DBIc_is(imp_sth, DBIcf_ChopBlanks);
\& if (!fetch_new_row_of_data(...)) {
\& ... /* check for error or end-of-data */
\& DBIc_ACTIVE_off(imp_sth); /* turn off Active flag automatically */
\& /* 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! */
There's no need to use a fetch_a_field function returning an SV*.
It's more common to use your database \s-1API\s0 functions to fetch the
data as character strings and use code like this:
\& sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);
\&\s-1NULL\s0 values must be returned as undef. You can use code like this:
\& SvOK_off(AvARRAY(av)[i]);
The function returns the \s-1AV\s0 prepared by \s-1DBI\s0 for success or \f(CW\*(C`Nullav\*(C'\fR
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 \s-1DBI\s0 docs for more background details.
All it \fIneeds\fR 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
\&\s-1ACTIVE\s0 to on for the sth.
Minimal example (the \s-1DBI\s0 default method just does this):
\& int dbd_st_finish(SV* sth, imp_sth_t* imp_sth) {
\& DBIc_ACTIVE_off(imp_sth);
The function returns \s-1TRUE\s0 for success, \s-1FALSE\s0 otherwise.
.IX Item "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 \s-1DBI\s0 Driver.xst code will call dbd_st_finish for you, if the sth has
the \s-1ACTIVE\s0 flag set, before calling dbd_st_destroy.
.IP "dbd_st_STORE_attrib" 2
.IX Item "dbd_st_STORE_attrib"
.IP "dbd_st_FETCH_attrib" 2
.IX Item "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* dbd_st_FETCH_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv);
This function is internally used by the \fIbind_param\fR method, the
\&\fIbind_param_inout\fR method and by the \s-1DBI\s0 Driver.xst code if \f(CW\*(C`execute\*(C'\fR
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 \fIparam\fR argument holds an \s-1IV\s0 with the parameter number (1, 2, ...).
The \fIvalue\fR argument is the parameter value and \fIsql_type\fR is its type.
If your driver does not support bind_param_inout then you should
ignore \fImaxlen\fR and croak if \fIis_inout\fR is \s-1TRUE\s0.
If your driver \fIdoes\fR support bind_param_inout then you should
note that \fIvalue\fR is the \s-1SV\s0 \fIafter\fR 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 \fIdbd_st_execute\fR.
See the \fIDBD::mysql\fR driver for an example.
.Sh "Implementing bind_param_inout support"
.IX Subsection "Implementing bind_param_inout support"
To provide support for parameters bound by reference rather than by
value, the driver must do a number of things. First, and most
importantly, it must note the references and stash them in its own
driver structure. Secondly, when a value is bound to a column, the
driver must discard any previous reference bound to the column. On
each execute, the driver must evaluate the references and internally
bind the values resulting from the references. This is only applicable
\& $sth->execute(@values);
then \s-1DBI\s0 automatically calls the binding code for each element of
\&\f(CW@values\fR. These calls are indistinguishable from explicit user calls to
.IX Subsection "Makefile.PL"
This is exactly as in the Pure Perl case. To be honest, the above
Makefile.PL contains some things that are superfluous for Pure Perl
.SH "METHODS WHICH DO NOT NEED TO BE WRITTEN"
.IX Header "METHODS WHICH DO NOT NEED TO BE WRITTEN"
The \s-1DBI\s0 code implements the majority of the methods which are
accessed using the notation \s-1DBI\-\s0>\fIfunction()\fR, the only exceptions being
\&\s-1DBI\-\s0>\fIconnect()\fR and \s-1DBI\-\s0>\fIdata_sources()\fR which require support from the
The \s-1DBI\s0 code implements the following documented driver, database and
statement functions which do not need to be written by the \s-1DBD\s0 driver
.IP "$dbh\->\fIdo()\fR" 4
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 \s-1EXECUTE\s0 \s-1IMMEDIATE\s0 which can
sometimes be used if there are no parameters.
.IP "$h\->\fIerrstr()\fR" 4
.IP "$h\->\fIstate()\fR" 4
.IP "$h\->\fItrace()\fR" 4
The \s-1DBD\s0 driver does not need to worry about these routines at all.
.IP "$h\->{ChopBlanks}" 4
.IX Item "$h->{ChopBlanks}"
This attribute needs to be honured during fetch operations, but does
not need to be handled by the attribute handling code.
.IP "$h\->{RaiseError}" 4
.IX Item "$h->{RaiseError}"
The \s-1DBD\s0 driver does not need to worry about this attribute at all.
.IP "$h\->{PrintError}" 4
.IX Item "$h->{PrintError}"
The \s-1DBD\s0 driver does not need to worry about this attribute at all.
.IP "$sth\->\fIbind_col()\fR" 4
.IX Item "$sth->bind_col()"
Assuming the driver uses the \s-1DBIS\-\s0>\fIget_fbav()\fR function (C drivers,
see below), or the \f(CW$sth\fR\->_set_fbav($data) method (Perl drivers)
the driver does not need to do anything about this routine.
.IP "$sth\->\fIbind_columns()\fR" 4
.IX Item "$sth->bind_columns()"
Regardless of whether the driver uses \s-1DBIS\-\s0>\fIget_fbav()\fR, the driver
does not need to do anything about this routine as it simply
iteratively calls \f(CW$sth\fR\->\fIbind_col()\fR.
The \s-1DBI\s0 code implements a default implementation of the following
functions which do not need to be written by the \s-1DBD\s0 driver writer
unless the default implementation is incorrect for the Driver.
.IP "$dbh\->\fIquote()\fR" 4
This should only be written if the database does not accept the \s-1ANSI\s0
\&\s-1SQL\s0 standard for quoting strings, with the string enclosed in single
quotes and any embedded single quotes replaced by two consecutive
For the two argument form of quote, you need to implement the
\&\f(CW\*(C`type_info\*(C'\fR method to provide the information that quote needs.
.IP "$dbh\->\fIping()\fR" 4
This should be implemented as a simple efficient way to determine
whether the connection to the database is still alive. Typically
\& $sth = $dbh->prepare_cached(q{
\& select * from A_TABLE_NAME where 1=0
\& $sth->execute or return 0;
where A_TABLE_NAME is the name of a table that always exists (such as a
database system catalogue).
.SH "WRITING AN EMULATION LAYER FOR AN OLD PERL INTERFACE"
.IX Header "WRITING AN EMULATION LAYER FOR AN OLD PERL INTERFACE"
Study Oraperl.pm (supplied with DBD::Oracle) and Ingperl.pm (supplied
with DBD::Ingres) and the corresponding dbdimp.c files for ideas.
Note that the emulation code sets \f(CW$dbh\fR\->{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.
.Sh "Setting emulation perl variables"
.IX Subsection "Setting emulation perl variables"
For example, ingperl has a \f(CW$sql_rowcount\fR variable. Rather than try
to manually update this in Ingperl.pm it can be done faster in C code.
\& sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);
In the relevant places do:
\& if (DBIc_COMPAT(imp_sth)) /* only do this for compatibility mode handles */
\& sv_setiv(sql_rowcount, the_row_count);
.SH "OTHER MISCELLANEOUS INFORMATION"
.IX Header "OTHER MISCELLANEOUS INFORMATION"
.Sh "The imp_xyz_t types"
.IX Subsection "The imp_xyz_t types"
Any handle has a corresponding C structure filled with private data.
Some of this data is reserved for use by \s-1DBI\s0 (except for using the
DBIc macros below), some is for you. See the description of the
\&\fIdbdimp.h\fR file above for examples. The most functions in dbdimp.c
are passed both the handle \f(CW\*(C`xyz\*(C'\fR and a pointer to \f(CW\*(C`imp_xyz\*(C'\fR. In
rare cases, however, you may use the following macros:
.IX Item "D_imp_dbh(dbh)"
Given a function argument \fIdbh\fR, declare a variable \fIimp_dbh\fR 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.
.IX Item "D_imp_sth(sth)"
Likewise for statement handles.
Given any handle, declare a variable \fIimp_xxx\fR and initialize it
with a pointer to the handles private data. It is safe, for example,
to cast \fIimp_xxx\fR to \f(CW\*(C`imp_dbh_t*\*(C'\fR, if DBIc_TYPE(imp_xxx) == DBIt_DB.
(You can also call sv_derived_from(h, \*(L"DBI::db\*(R"), but that's much
.IP "D_imp_sth_from_dbh" 2
.IX Item "D_imp_sth_from_dbh"
Given a imp_sth, declare a variable \fIimp_dbh\fR and initialize it with a
pointer to the parent database handles implementors structure.
.Sh "Using DBIc_IMPSET_on"
.IX Subsection "Using DBIc_IMPSET_on"
The driver code which initializes a handle should use \fIDBIc_IMPSET_on()\fR
as soon as its state is such that the cleanup code must be called.
When this happens is determined by your driver code.
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 \fIDBIc_IMPSET_on()\fR was being called too late, it was able to cause
.Sh "Using \fIDBIc_is()\fP, \fIDBIc_has()\fP, \fIDBIc_on()\fP and \fIDBIc_off()\fP"
.IX Subsection "Using DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off()"
Once upon a long time ago, the only way of handling the internal \s-1DBI\s0
boolean flags/attributes was through macros such as:
\& DBIc_WARN DBIc_WARN_on DBIc_WARN_off
\& DBIc_COMPAT DBIc_COMPAT_on DBIc_COMPAT_off
Each of these took an imp_xxh pointer as an argument.
Since then, new attributes have been added such as ChopBlanks,
RaiseError and PrintError, and these do not have the full set of
The approved method for handling these is now the four macros:
\& DBIc_has(imp, flag) an alias for DBIc_is
Consequently, the DBIc_XXXXX family of macros is now mostly deprecated
and new drivers should avoid using them, even though the older drivers
will probably continue to do so for quite a while yet. However...
There is an \fIimportant exception\fR to that. The \s-1ACTIVE\s0 and \s-1IMPSET\s0
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.
.Sh "Using \s-1DBIS\-\s0>\fIget_fbav()\fP"
.IX Subsection "Using DBIS->get_fbav()"
The \f(CW$sth\fR\->\fIbind_col()\fR and \f(CW$sth\fR\->\fIbind_columns()\fR documented in the \s-1DBI\s0
specification do not have to be implemented by the driver writer
becuase \s-1DBI\s0 takes care of the details for you.
However, the key to ensuring that bound columns work is to call the
function \s-1DBIS\-\s0>\fIget_fbav()\fR in the code which fetches a row of data.
This returns an \s-1AV\s0, and each element of the \s-1AV\s0 contains the \s-1SV\s0 which
should be set to contain the returned data.
The above is for C drivers only. The Perl equivalent is the
\&\f(CW$sth\fR\->_set_fbav($data) method, as described in the part on Pure
.SH "SUBCLASSING DBI DRIVERS"
.IX Header "SUBCLASSING DBI DRIVERS"
This is definitely an open subject. It can be done, as demonstrated by
the \fIDBD::File\fR driver, but it is not as simple as one might think.
(Note that this topic is different from subclassing the \s-1DBI\s0. For an
example of that, see the t/subclass.t file supplied with the \s-1DBI\s0.)
The main problem is that the dbh's and sth's that your \fIconnect\fR and
\&\fIprepare\fR methods return are not instances of your \fIDBD::Driver::db\fR
or \fIDBD::Driver::st\fR packages, they are not even derived from it.
Instead they are instances of the \fIDBI::db\fR or \fIDBI::st\fR classes or
a derived subclass. Thus, if you write a method \fImymethod\fR and do a
then the autoloader will search for that method in the package \fIDBI::db\fR.
Of course you can instead to a
\& $dbh->func('mymethod')
and that will indeed work, even if \fImymethod\fR is inherited, but not
without additional work. Setting \f(CW@ISA\fR is not sufficient.
.Sh "Overwriting methods"
.IX Subsection "Overwriting methods"
The first problem is, that the \fIconnect\fR method has no idea of
subclasses. For example, you cannot implement base class and subclass
in the same file: The \fIinstall_driver\fR method wants to do a
In particular, your subclass \fBhas\fR to be a separate driver, from
the view of \s-1DBI\s0, and you cannot share driver handles.
Of course that's not much of a problem. You should even be able
to inherit the base classes \fIconnect\fR method. But you cannot
simply overwrite the method, unless you do something like this,
quoted from \fI\s-1DBD::CSV\s0\fR:
\& 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} = {};
\& $srh->SUPER::connect($dbname, $user, $auth, $attr);
as we would usually do in a an \s-1OO\s0 environment, because \f(CW$drh\fR is an instance
of \fIDBI::dr\fR. And note, that the \fIconnect\fR method of \fIDBD::File\fR is
able to handle subclass attributes. See the description of Pure Perl
It is essential that you always call superclass method in the above
manner. However, that should do.
.IX Subsection "Attribute handling"
Fortunately the \s-1DBI\s0 specs allow a simple, but still performant way of
handling attributes. The idea is based on the convention that any
driver uses a prefix \fIdriver_\fR for its private methods. Thus it's
always clear whether to pass attributes to the super class or not.
For example, consider this \s-1STORE\s0 method from the \fI\s-1DBD::CSV\s0\fR class:
\& my($dbh, $attr, $val) = @_;
\& if ($attr !~ /^driver_/) {
\& return $dbh->DBD::File::db::STORE($attr, $val);
\& if ($attr eq 'driver_foo') {
.IX Header "ACKNOWLEDGEMENTS"
Tim Bunce \- for writing \s-1DBI\s0 and managing the \s-1DBI\s0 specification and the
Jonathan Leffler <jleffler@informix.com>,
Jochen Wiedmann <joe@ispsoft.de>,
projects / OpenSPARC-T2-DV / blob