# $Id: DBD.pm,v 11.11 2002/11/30 00:46:18 timbo Exp $ # # Copyright (c) 1997-2002 Jonathan Leffler, Jochen Wiedmann, Steffen # Goeldner and Tim Bunce # # You may distribute under the terms of either the GNU General Public # License or the Artistic License, as specified in the Perl README file. =head1 NAME DBI::DBD - DBD Driver Writer's Guide =head1 SYNOPSIS perldoc DBI::DBD =head1 VERSION and VOLATILITY $Revision: 11.11 $ $Date: 2002/11/30 00:46:18 $ This document is I a minimal draft which is in need of further work. 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. =head1 DESCRIPTION This document is primarily intended to help people writing new database drivers for the Perl Database Interface (Perl DBI). It may also help others interested in discovering why the internals of a DBD 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 I 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://dbi.perl.org/ There are 2 main and one auxilliary mailing lists for people working with DBI. The primary lists are dbi-users@perl.org for general users of DBI and DBD drivers, and dbi-dev@perl.org mainly for DBD driver writers (don't join the dbi-dev list unless you have a good reason). The auxilliary list is dbi-announce@perl.org for announcing new releases of DBI or DBD drivers. You can join these lists by accessing the web-site L. 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, especially comp.lang.perl.modules. =head1 BOOK The definitive book on Perl DBI is 'Programming the Perl DBI: Database programming with Perl' by Alligator Descartes and Tim Bunce, published by O'Reilly Associates, February 2000, ISBN 1-56592-699-4. Buy it now if you have not already done so. =head1 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 own! =head2 Locating drivers The primary web-site for locating Perl software is L. You should look under the various modules listings for the software you are after. For example: http://search.cpan.org/modlist/Database_Interfaces Follow the DBD:: and DBIx:: links at the top to see those subsets. See the DBI docs for information on DBI web sites and mailing lists. =head2 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 DBI mailing lists whether there is such a driver available, or whether anybody is working on one. =head1 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 after the other. Also look carefully at DBD::AnyData and DBD::Template. As an example we take a look at the I driver, a driver for accessing plain files as tables, which is part of the I package. In what follows I assume the name C for your new package: The least thing we have to implement are the files C and C. =head2 Makefile.PL You typically start with writing C, 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 I, I, I, I, I, I, I, I, I, I, I, I, I, I, I from the C man page: These are used in almost any Makefile.PL. Additionally read the section on I and the descriptions of the I, I and I targets: They will definitely be useful for you. Of special importance for DBI drivers is the I method from the C man page. And for Emacs users I recommend the I method. Now an example, I use the word C wherever you should insert your driver's name: # -*- perl -*- use DBI 1.03; use DBI::DBD; use ExtUtils::MakeMaker; WriteMakefile( dbd_edit_mm_attribs( { 'NAME' => 'DBD::Driver', 'VERSION_FROM' => 'Driver.pm', 'INC' => $DBI_INC_DIR, 'dist' => { 'SUFFIX' => '.gz', 'COMPRESS' => 'gzip -9f' }, 'realclean' => { FILES => '*.xsi' }, } ) ); package MY; sub postamble { return main::dbd_postamble(@_); } sub libscan { my ($self, $path) = @_; ($path =~ m/\~$/) ? undef : $path; } Note the calls to dbd_edit_mm_attribs() and dbd_postamble(). See also L. L. =head2 README file The README 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 README from one of the established drivers as a basis for your own. =head2 MANIFEST The MANIFEST will be used by the Makefile's dist target to build the distribution tar file that is uploaded to CPAN. It should list every file that you want to include in your distribution, one per line. =head2 lib/Bundle/DBD/Driver.pm The CPAN 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 some more. 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 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 =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 =head1 SEE ALSO Bundle::DBI =head1 AUTHOR Your Name EFE =head1 THANKS This bundle was created by ripping off Bundle::libnet created by Graham Barr EFE, and radically simplified with some information from Jochen Wiedmann EFE. The template was then included in the DBI::DBD documentation by Jonathan Leffler EFE. =cut =head2 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 driver() which will have a more or less standard structure. 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. =over 2 =item 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 I 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. =item 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 I method is the driver handle constructor. It's a reasonable example of how DBI implements its handles. There are three kinds: B (typically stored in C<$drh>, from now on called C), B (from now on called C or C<$dbh>) and B, (from now on called C or C<$sth>). The prototype of DBI::_new_drh is $drh = DBI::_new_drh($class, $attr1, $attr2); with the following arguments: =over 4 =item I<$class> is typically your drivers class, e.g., "DBD::File::dr", passed as first argument to the I method. =item I<$attr1> is a hash ref to attributes like I, I, I, I I and I. These are processed and used by DBI, you better not make any assumptions on them nor should you add private attributes here. =item I<$attr2> This is another (optional) hash ref with your private attributes. DBI will leave them alone. =back The I method and the I method both return C for failure (in which case you must look at $DBI::err and $DBI::errstr, because you have no driver handle). =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 @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 I above. The arguments are described in the DBI man page. See L. 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 I, the exception being C<$class> replaced by C<$drh>. Note the use of the I 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. =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 attribute. To report an error, you use the C 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 ...; =item Other driver handle methods may follow here. In particular you should consider a I method, and a (possibly empty) I method. See L. =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; 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 I. Note the prefix I 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 I. We could as well do this in the I method below, the DBI specs explicitly allow to defer this. However, one could not call I in that case. =item Transaction handling Pure Perl drivers will rarely support transactions. Thus you're I and I methods will typically be quite simple: sub commit { my ($dbh) = @_; if ($dbh->FETCH('Warn')) { warn("Commit ineffective while AutoCommit is on"); } 0; } sub rollback { my ($dbh) = @_; if ($dbh->FETCH('Warn')) { warn("Rollback ineffective while AutoCommit is on"); } 0; } Or even simpler, just use the default methods provided by the DBI that do nothing except return undef. The DBI's default begin_work method can be used by inheritance. =item 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 L 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 I or I. 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. =item Other database handle methods may follow here. In particular you should consider a (possibly empty) I method, a I method (if DBI's default isn't good for you). =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 I 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 I to work. And we use attribute I<$sth->{'Statement'}> which we have created within I. The attribute I<$sth->{'Database'}>, which is nothing else than the I, 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. =item Fetching data We need not implement the methods I, I, ... because these are already part of DBI. All we need is the method I: 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 I<_set_fbav>: This is required so that I and I work. Fixing the broken implementation for correct handling of quoted question marks is left as an exercise to the reader. :-) =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 DBI: For example I, I, I, ... Besides that the STORE and FETCH methods are mainly the same as above for dbh's. =item Other statement methods A trivial C method to discard the stored data and do $sth->SUPER::finish; A C method to return details of available tables. A C 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. =back =head2 Tests The test process should conform as closely as possibly to the Perl standard test harness. 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 L. 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...] =head1 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 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...] =head2 REQUIREMENTS ON A DRIVER T.B.S. =head2 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: =over 4 =item Driver.pm =item Driver.xs =item Driver.h =item dbdimp.h =item dbdimp.c =item Makefile.PL =item README =item MANIFEST =item lib/Bundle/DBD/Driver.pm =back =head2 Driver.pm The Driver.pm file is the same as for Pure Perl modules, see above. However, there are some subtle differences: =over 8 =item * 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. =item * Some methods are typically moved to the XS code, in particular I, I, I, I and the STORE and FETCH methods. =item * Other methods are still part of C, but have callbacks in the XS code. =back 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. =over 2 =item 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, }) or return undef; # 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 I<_login> callback: This will really connect to the database. It is implemented in Driver.xst (you should not implement it) and calls I from I. See below for details. =over 4 *FIX ME* Discuss removing attributes from hash reference as an optimization to skip later calls to $dbh->STORE made by DBI->connect. =back =item The statement handle constructor There's nothing much new in the statement handle constructor. Like the I 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; } =back =head2 Driver.xs Driver.xs should look something like this: #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. */ Note especially the include of I here: DBI 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 I: This is what you have to implement. =head2 Driver.h Driver.h should look like this: #define NEED_DBIXS_VERSION 93 #include /* installed by the DBI module */ #include "dbdimp.h" #include /* installed by the DBI module */ =head2 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 I to database specific names like I. 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 C 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 I and I. (DBD::mysql was a port of DBD::mSQL which was based on DBD::Oracle.) This part of the driver is I. 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_login6 ora_db_login #define dbd_db_do ora_db_do ... many more here ... =over 4 *FIX ME* Should use hypothetical drv_ prefix instead of ora_ prefix. =back These structures implement your private part of the handles. You I to use the name I and the first field I be of type I and I be called C. You should never access these fields directly, except of using the I macros below. =head2 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 I template and thus B to be implemented. Of course you can add private or better static functions here. Since Perl 5.6 requires support for function prototypes (ANSI or ISO or Standard C), you should write your code using function prototypes too. =over 2 =item 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 I in turn. =over 4 *FIX ME* Is recommended practice to use the unmapped DBI-specified names or to use your driver-specific function names in the source code? DBD::Informix uses the driver-specific names in the source; the header deals with the mapping. ANSWER: Not very significant, but using the unmapped DBI-specified names (dbd_*) makes it a little easier to compare code between drivers and eases discussions on the dbi-dev mailing list. =back =item do_error You need a function to handle recording of errors. You can call it whatever you like, but we'll call it C here. =over 4 *FIX ME* Should this be a file static function? Why not? =back void do_error(SV* h, int rc, char* what) { Note that I 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 I with a pointer to your private handle pointer. You may cast this to to I, I or I. 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 I and I 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! =item dbd_db_login6 int dbd_db_login6(SV* dbh, imp_dbh_t* imp_dbh, char* dbname, char* user, char* auth, SV *attr); This function will really connect to the database. The argument I is the database handle. I is the pointer to the handles private data, as is I in I above. The arguments I, I and I correspond to the arguments of the driver handles I method. You will quite often use database specific attributes here, that are specified in the DSN. I recommend you parse the DSN within the I method and pass them as \%attr thru I<_login> to I. Here's how you fetch them, as an example we use I and I attributes: SV** svp; STRLEN len; char* hostname; if ( (svp = DBD_ATTRIB_GET_SVP(attr, "drv_hostname", 12)) && SvTRUE(*svp)) { hostname = SvPV(*svp, len); DBD__ATTRIB_DELETE(attr, "drv_hostname", 12); /* avoid later STORE */ } else { hostname = "localhost"; } 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_login6 function should return TRUE for success, FALSE otherwise. =item dbd_db_commit =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 TRUE for success, FALSE for error. The arguments I and I are like above, I will omit describing them in what follows, as they appear always. =item dbd_db_disconnect This is your private part of the I method. Any dbh with the I flag on must be disconnected. (Note that you have to set it in I 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 I was executed. Note that there's noting to stop a dbh being I while it still have active children. If your database API reacts badly to trying to use an sth in this situation then you'll need to add code like this to all sth methods: if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth))) return 0; =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 but return 'success'. You guess what the return codes are? (Hint: See the last functions above ... :-) =item dbd_db_destroy This is your private part of the database handle destructor. Any dbh with the I flag on must be destroyed, so that you can safely free resources. (Note that you have to set it in I 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. A DBI handle doesn't keep references to its children. But children do keep references to their parents. So a database handle won't be DESTROY'd until all it's children have been DESTROY'd. =back =item 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; on the contrary, you should not handle DBI attributes here: Leave this to DBI. (There's one exception, I, 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 I, so DBI can raise exceptions, if desired. If I returns, however, you have a problem: The user will never know about the error, because he typically will not check C<$dbh-Eerrstr>. I cannot recommend a general way of going on, if I returns, but there are examples where even the DBI specification expects that you croak(). (See the I method in L.) 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. =item 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 C<&sv_undef>, C<&sv_no> and C<&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); =item dbd_st_prepare This is the private part of the I method. Note that you B 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 to do nothing and rely on the perl perpare() code that set the Statement attribute on the handle. This attribute can then be used by dbd_st_execute. If the driver supports placeholders then the NUM_OF_PARAMS attribute must be set correctly by dbd_st_prepare: DBIc_NUM_PARAMS(imp_sth) = ... If you can, you should also 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 I above: DBIc_IMPSET_on(imp_sth); =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 I will be called between two executions, so you'll probably want code like: if (DBIc_ACTIVE(imp_sth)) dbd_st_finish(h, imp_sth); If your driver supports binding of parameters (it should!), but the database doesn't, you must do it here. This can be done as follows: SV *svp; char* statement = DBD_ATTRIB_GET_PV(h, "Statement", 9, svp, ""); 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 comments 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 set the attributes NUM_OF_FIELDS, NAME, etc when the statement is successfully executed if the driver has not already done so. They may be used even before a potential I. 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 C