package DBI::DBD; # vim:ts=8:sw=4 use vars qw($VERSION); # set $VERSION early so we don't confuse PAUSE/CPAN etc # don't use Revision here because that's not in svn:keywords so that the # examples that use it below won't be messed up $VERSION = sprintf("12.%06d", q$Id: DBD.pm 10405 2007-12-11 10:00:19Z mjevans $ =~ /(\d+)/o); # $Id: DBD.pm 10405 2007-12-11 10:00:19Z mjevans $ # # Copyright (c) 1997-2006 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 - Perl DBI Database Driver Writer's Guide =head1 SYNOPSIS perldoc DBI::DBD =head2 Version and volatility This document is I a minimal draft which is in need of further work. The changes will occur both because the B specification is changing and hence the requirements on B drivers change, and because feedback from people reading this document will suggest improvements to it. Please read the B documentation first and fully, including the B FAQ. Then reread the B 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 B 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 I mailing list (details given below) where Tim Bunce and other driver authors can help. =head1 CREATING A NEW DRIVER The first rule for creating a new database driver for the Perl DBI is very simple: B There is usually a driver already available for the database you want to use, almost regardless of which database you choose. Very often, the database will provide an ODBC driver interface, so you can often use B to access the database. This is typically less convenient on a Unix box than on a Microsoft Windows box, but there are numerous options for ODBC driver managers on Unix too, and very often the ODBC driver is provided by the database supplier. Before deciding that you need to write a driver, do your homework to ensure that you are not wasting your energies. [As of December 2002, the consensus is that if you need an ODBC driver manager on Unix, then the unixODBC driver (available from L) is the way to go.] The second rule for creating a new database driver for the Perl DBI is also very simple: B Nevertheless, there are occasions when it is necessary to write a new driver, often to use a proprietary language or API to access the database more swiftly, or more comprehensively, than an ODBC driver can. Then you should read this document very carefully, but with a suitably sceptical eye. If there is something in here that does not make any sense, question it. You might be right that the information is bogus, but don't come to that conclusion too quickly. =head2 URLs and mailing lists The primary web-site for locating B software and information is http://dbi.perl.org/ There are two main and one auxilliary mailing lists for people working with B. The primary lists are I for general users of B and B drivers, and I mainly for B driver writers (don't join the I list unless you have a good reason). The auxilliary list is I for announcing new releases of B or B 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 I newsgroups, especially I. =head2 The Cheetah book The definitive book on Perl DBI is the Cheetah book, so called because of the picture on the cover. Its proper title is 'I' 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, and read it. =head2 Locating drivers 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! 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 B and B links at the top to see those subsets. See the B docs for information on B 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 B mailing lists whether there is such a driver available, or whether anybody is working on one. When you get the go ahead, you will need to establish the name of the driver and a prefix for the driver. Typically, the name is based on the name of the database software it uses, and the prefix is a contraction of that. Hence, B has the name I and the prefix 'I'. The prefix must be lowercase and contain no underscores other than the one at the end. This information will be recorded in the B module. Apart from documentation purposes, registration is a prerequisite for L. If you are writing a driver which will not be distributed on CPAN, then you should choose a prefix beginning with 'I', to avoid potential prefix collisions with drivers registered in the future. Thus, if you wrote a non-CPAN distributed driver called B, the prefix might be 'I'. This document assumes you are writing a driver called B, and that the prefix 'I' is assigned to the driver. =head2 Two styles of database driver There are two distinct styles of database driver that can be written to work with the Perl DBI. Your driver can be written in pure Perl, requiring no C compiler. When feasible, this is the best solution, but most databases are not written in such a way that this can be done. Some examples of pure Perl drivers are B and B. Alternatively, and most commonly, your driver will need to use some C code to gain access to the database. This will be classified as a C/XS driver. =head2 What code will you write? There are a number of files that need to be written for either a pure Perl driver or a C/XS driver. There are no extra files needed only by a pure Perl driver, but there are several extra files needed only by a C/XS driver. =head3 Files common to pure Perl and C/XS drivers Assuming that your driver is called B, these files are: =over 4 =item * F =item * F =item * F =item * F =item * F =item * F =item * F =item * F =back The first four files are mandatory. F is used to control how the driver is built and installed. The F file tells people who download the file about how to build the module and any prerequisite software that must be installed. The F file is used by the standard Perl module distribution mechanism. It lists all the source files that need to be distributed with your module. F is what is loaded by the B code; it contains the methods peculiar to your driver. Although the F file is not B you are advised to create one. Of particular importance are the I and I attributes which newer CPAN modules understand. You use these to tell the CPAN module (and CPANPLUS) that your build and configure mechanisms require DBI. The best reference for META.yml (at the time of writing) is L. You can find a reasonable example of a F in DBD::ODBC. The F file allows you to specify other Perl modules on which yours depends in a format that allows someone to type a simple command and ensure that all the pre-requisites are in place as well as building your driver. The F file contains (an updated version of) the information that was included - or that would have been included - in the appendices of the Cheetah book as a summary of the abilities of your driver and the associated database. The files in the F subdirectory are unit tests for your driver. You should write your tests as stringently as possible, while taking into account the diversity of installations that you can encounter: =over 4 =item * Your tests should not casually modify operational databases. =item * You should never damage existing tables in a database. =item * You should code your tests to use a constrained name space within the database. For example, the tables (and all other named objects) that are created could all begin with 'I'. =item * At the end of a test run, there should be no testing objects left behind in the database. =item * If you create any databases, you should remove them. =item * If your database supports temporary tables that are automatically removed at the end of a session, then exploit them as often as possible. =item * Try to make your tests independent of each other. If you have a test F that depends upon the successful running of F, people cannot run the single test case F. Further, running F twice in a row is likely to fail (at least, if F modifies the database at all) because the database at the start of the second run is not what you saw at the start of the first run. =item * Document in your F file what you do, and what privileges people need to do it. =item * You can, and probably should, sequence your tests by including a test number before an abbreviated version of the test name; the tests are run in the order in which the names are expanded by shell-style globbing. =item * It is in your interests to ensure that your tests work as widely as possible. =back Many drivers also install sub-modules B for any of a variety of different reasons, such as to support the metadata methods (see the discussion of L below). Such sub-modules are conventionally stored in the directory F. The module itself would usually be in a file F. All such sub-modules should themselves be version stamped (see the discussions far below). =head3 Extra files needed by C/XS drivers The software for a C/XS driver will typically contain at least four extra files that are not relevant to a pure Perl driver. =over 4 =item * F =item * F =item * F =item * F =back The F file is used to generate C code that Perl can call to gain access to the C functions you write that will, in turn, call down onto your database software. The F header is a stylized header that ensures you can access the necessary Perl and B macros, types, and function declarations. The F is used to specify which functions have been implemented by your driver. The F file is where you write the C code that does the real work of translating between Perl-ish data types and what the database expects to use and return. There are some (mainly small, but very important) differences between the contents of F and F for pure Perl and C/XS drivers, so those files are described both in the section on creating a pure Perl driver and in the section on creating a C/XS driver. Obviously, you can add extra source code files to the list. =head2 Requirements on a driver and driver writer To be remotely useful, your driver must be implemented in a format that allows it to be distributed via CPAN, the Comprehensive Perl Archive Network (L and L). Of course, it is easier if you do not have to meet this criterion, but you will not be able to ask for much help if you do not do so, and no-one is likely to want to install your module if they have to learn a new installation mechanism. =head1 CREATING A PURE PERL DRIVER Writing a pure Perl driver is surprisingly simple. However, there are some problems you 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 B and B. As an example we take a look at the B driver, a driver for accessing plain files as tables, which is part of the B package. The minimal set of files we have to implement are F, F, F and F. =head2 Pure Perl version of Makefile.PL You typically start with writing F, a Makefile generator. The contents of this file are described in detail in the L man pages. It is 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, I from the L man page: these are used in almost any F. 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 B drivers is the I method from the L man page. For Emacs users, I recommend the I method, which removes Emacs backup files (file names which end with a tilde '~') from lists of files. Now an example, I use the word C wherever you should insert your driver's name: # -*- perl -*- use ExtUtils::MakeMaker; WriteMakefile( dbd_edit_mm_attribs( { 'NAME' => 'DBD::Driver', 'VERSION_FROM' => 'Driver.pm', 'INC' => '', 'dist' => { 'SUFFIX' => '.gz', 'COMPRESS' => 'gzip -9f' }, 'realclean' => { FILES => '*.xsi' }, 'PREREQ_PM' => '1.03', 'CONFIGURE' => sub { eval {require DBI::DBD;}; if ($@) { warn $@; exit 0; } my $dbi_arch_dir = dbd_dbi_arch_dir(); if (exists($opts{INC})) { return {INC => "$opts{INC} -I$dbi_arch_dir"}; } else { return {INC => "-I$dbi_arch_dir"}; } } }, { create_pp_tests => 1}) ); package MY; sub postamble { return main::dbd_postamble(@_); } sub libscan { my ($self, $path) = @_; ($path =~ m/\~$/) ? undef : $path; } Note the calls to C and C. The second hash reference in the call to C (containing C) is optional; you should not use it unless your driver is a pure Perl driver (that is, it does not use C and XS code). Therefore, the call to C is not relevant for C/XS drivers and may be omitted; simply use the (single) hash reference containing NAME etc as the only argument to C. Note that the C code will fail if you do not have a F sub-directory containing at least one test case. I tells MakeMaker that DBI (version 1.03 in this case) is required for this module. This will issue a warning that DBI 1.03 is missing if someone attempts to install your DBD without DBI 1.03. See I below for why this does not work reliably in stopping cpan testers failing your module if DBI is not installed. I is a subroutine called by MakeMaker during C. By putting the C in this section we can attempt to load DBI::DBD but if it is missing we exit with success. As we exit successfully without creating a Makefile when DBI::DBD is missing cpan testers will not report a failure. This may seem at odds with I but I does not cause C to fail (unless you also specify PREREQ_FATAL which is strongly discouraged by MakeMaker) so C would continue to call C and fail. All drivers must use C or risk running into problems. Note the specification of I; the named file (F) will be scanned for the first line that looks like an assignment to I<$VERSION>, and the subsequent text will be used to determine the version number. Note the commentary in L on the subject of correctly formatted version numbers. If your driver depends upon external software (it usually will), you will need to add code to ensure that your environment is workable before the call to C. If you need to check for the existance of an external library and perhaps modify I to include the paths to where the external library header files are located and you cannot find the library or header files make sure you output a message saying they cannot be found but C (success) B calling C or CPAN testers will fail your module if the external library is not found. A full-fledged I can be quite large (for example, the files for B and B are both over 1000 lines long, and the Informix one uses - and creates - auxilliary modules too). See also L and L. Consider using L in place of I. =head2 README The L file should describe what the driver is for, the pre-requisites for the build process, the actual build process, how to report errors, and who to report them to. Users will find ways of breaking the driver build and test process which you would never even have dreamed to be possible in your worst nightmares. Therefore, you need to write this document defensively, precisely and concisely. As always, use the F from one of the established drivers as a basis for your own; the version in B is worth a look as it has been quite successful in heading off problems. =over 4 =item * Note that users will have versions of Perl and B that are both older and newer than you expected, but this will seldom cause much trouble. When it does, it will be because you are using features of B that are not supported in the version they are using. =item * Note that users will have versions of the database software that are both older and newer than you expected. You will save yourself time in the long run if you can identify the range of versions which have been tested and warn about versions which are not known to be OK. =item * Note that many people trying to install your driver will not be experts in the database software. =item * Note that many people trying to install your driver will not be experts in C or Perl. =back =head2 MANIFEST The F 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 B; 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. The prerequisite modules are listed in the C section, with the official name of the module followed by a dash and an informal name or description. =over 4 =item * Listing B as the main pre-requisite simplifies life. =item * Don't forget to list your driver. =item * Note that unless the DBMS is itself a Perl module, you cannot list it as a pre-requisite in this file. =item * You should keep the version of the bundle the same as the version of your driver. =item * You should add configuration management, copyright, and licencing information at the top. =back A suitable skeleton for this file is shown below. 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 lib/DBD/Driver/Summary.pm There is no substitute for taking the summary file from a driver that was documented in the Perl book (such as B or B or B, to name but three), and adapting it to describe the facilities available via B when accessing the Driver database. =head2 Pure Perl version of Driver.pm The F file defines the Perl module B for your driver. It will define a package B along with some version information, some variable definitions, and a function C which will have a more or less standard structure. It will also define three sub-packages of B: =over 4 =item DBD::Driver::dr with methods C, C and C; =item DBD::Driver::db with methods such as C; =item DBD::Driver::st with methods such as C and C. =back The F file will also contain the documentation specific to B in the format used by perldoc. In a pure Perl driver, the F file is the core of the implementation. You will need to provide all the key methods needed by B. Now let's take a closer look at an excerpt of F as an example. We ignore things that are common to any module (even non-DBI modules) or really specific to the B package. =head3 The DBD::Driver package =head4 The header package DBD::File; use strict; use vars qw($VERSION $drh); $VERSION = "1.23.00" # Version number of DBD::File This is where the version number of your driver is specified, and is where F looks for this information. Please ensure that any other modules added with your driver are also version stamped so that CPAN does not get confused. It is recommended that you use a two-part (1.23) or three-part (1.23.45) version number. Also consider the CPAN system, which gets confused and considers version 1.10 to precede version 1.9, so that using a raw CVS, RCS or SCCS version number is probably not appropriate (despite being very common). For Subversion you could use: $VERSION = sprintf("12.%06d", q$Revision: 12345 $ =~ /(\d+)/o); (use lots of leading zeros on the second portion so if you move the code to a shared repository like svn.perl.org the much larger revision numbers won't cause a problem, at least not for a few years). For RCS or CVS you can use: $VERSION = sprintf "%d.%02d", '$Revision: 11.21 $ ' =~ /(\d+)\.(\d+)/; which pads out the fractional part with leading zeros so all is well (so long as you don't go past x.99) $drh = undef; # holds driver handle once initialized This is where the driver handle will be stored, once created. Note that you may assume there is only one handle for your driver. =head4 The driver constructor The C method is the driver handle constructor. Note that the C method is in the B package, not in one of the sub-packages B, B, or B. sub driver { return $drh if $drh; # already created - return same one my ($class, $attr) = @_; $class .= "::dr"; DBD::Driver::db->install_method('drv_example_dbh_method'); DBD::Driver::st->install_method('drv_example_sth_method'); # not a 'my' since we use it above to prevent multiple drivers $drh = DBI::_new_drh($class, { 'Name' => 'File', 'Version' => $VERSION, 'Attribution' => 'DBD::File by Jochen Wiedmann', }) or return undef; return $drh; } This is a reasonable example of how B implements its handles. There are three kinds: B (typically stored in I<$drh>; from now on called I or I<$drh>), B (from now on called I or I<$dbh>) and B (from now on called I or I<$sth>). The prototype of C is $drh = DBI::_new_drh($class, $public_attrs, $private_attrs); with the following arguments: =over 4 =item I<$class> is typically the class for your driver, (for example, "DBD::File::dr"), passed as the first argument to the C method. =item I<$public_attrs> is a hash ref to attributes like I, I, and I. These are processed and used by B. You had better not make any assumptions about them nor should you add private attributes here. =item I<$private_attrs> This is another (optional) hash ref with your private attributes. B will store them and otherwise leave them alone. =back The C method and the C method both return C for failure (in which case you must look at I<$DBI::err> and I<$DBI::errstr> for the failure information, because you have no driver handle to use). =head4 Using install_method() to expose driver-private methods DBD::Foo::db->install_method($method_name, \%attr); Installs the driver-private method named by $method_name into the DBI method dispatcher so it can be called directly, avoiding the need to use the func() method. It is called as a static method on the driver class to which the method belongs. The method name must begin with the corresponding registered driver-private prefix. For example, for DBD::Oracle $method_name must being with 'C', and for DBD::AnyData it must begin with 'C'. The attributes can be used to provide fine control over how the DBI dispatcher handles the dispatching of the method. However, at this point, it's undocumented and very liable to change. (Volunteers to polish up and document the interface are very welcome to get in touch via dbi-dev@perl.org) Methods installed using install_method default to the standard error handling behaviour for DBI methods: clearing err and errstr before calling the method, and checking for errors to trigger RaiseError etc. on return. This differs from the default behaviour of func(). Note for driver authors: The DBD::Foo::xx->install_method call won't work until the class-hierarchy has been setup. Normally the DBI looks after that just after the driver is loaded. This means install_method() can't be called at the time the driver is loaded unless the class-hierarchy is set up first. The way to do that is to call the setup_driver() method: DBI->setup_driver('DBD::Foo'); before using install_method(). =head4 The CLONE special subroutine Also needed here, in the B package, is a C method that will be called by perl when an intrepreter is cloned. All your C method needs to do, currently, is clear the cached I<$drh> so the new interpreter won't start using the cached I<$drh> from the old interpreter: sub CLONE { undef $drh; } See L for details. =head3 The DBD::Driver::dr package The next lines of code look as follows: package DBD::Driver::dr; # ====== DRIVER ====== $DBD::Driver::dr::imp_data_size = 0; Note that no I<@ISA> is needed here, or for the other B classes, because the B takes care of that for you when the driver is loaded. *FIX ME* Explain what the imp_data_size is, so that implementors aren't practicing cargo-cult programming. =head4 The database handle constructor The database handle constructor is the driver's (hence the changed namespace) C method: sub connect { my ($drh, $dr_dsn, $user, $auth, $attr) = @_; # Some database specific verifications, default settings # and the like can go here. This should only include # syntax checks or similar stuff where it's legal to # 'die' in case of errors. # For example, many database packages requires specific # environment variables to be set; this could be where you # validate that they are set, or default them if they are not set. my $driver_prefix = "drv_"; # the assigned prefix for this driver # Process attributes from the DSN; we assume ODBC syntax # here, that is, the DSN looks like var1=val1;...;varN=valN foreach my $var ( split /;/, $dr_dsn ) { my ($attr_name, $attr_value) = split '=', $var, 2; return $drh->set_err($DBI::stderr, "Can't parse DSN part '$var'") unless defined $attr_value; # add driver prefix to attribute name if it doesn't have it already $attr_name = $driver_prefix.$attr_name unless $attr_name =~ /^$driver_prefix/o; # Store attribute into %$attr, replacing any existing value. # The DBI will STORE() these into $dbh after we've connected $attr->{$attr_name} = $attr_value; } # Get the attributes we'll use to connect. # We use delete here because these no need to STORE them my $db = delete $attr->{drv_database} || delete $attr->{drv_db} or return $drh->set_err($DBI::stderr, "No database name given in DSN '$dr_dsn'"); my $host = delete $attr->{drv_host} || 'localhost'; my $port = delete $attr->{drv_port} || 123456; # Assume you can attach to your database via drv_connect: my $connection = drv_connect($db, $host, $port, $user, $auth) or return $drh->set_err($DBI::stderr, "Can't connect to $dr_dsn: ..."); # create a 'blank' dbh (call superclass constructor) my ($outer, $dbh) = DBI::_new_dbh($drh, { Name => $dr_dsn }); $dbh->STORE('Active', 1 ); $dbh->{drv_connection} = $connection; return $outer; } This is mostly the same as in the I above. The arguments are described in L. The constructor C is called, returning a database handle. The constructor's prototype is: ($outer, $inner) = DBI::_new_dbh($drh, $public_attr, $private_attr); with similar arguments to those in the I, except that the I<$class> is replaced by I<$drh>. The I attribute is a standard B attribute (see L). In scalar context, only the outer handle is returned. Note the use of the C method for setting the I 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 B like I, don't actually exist in the hash and must be read via C<$h-EFETCH($attrib)> and set via C<$h-ESTORE($attrib, $value)>. If in any doubt, use these methods. =head4 The data_sources() method The C method must populate and return a list of valid data sources, prefixed with the "I" incantation that allows them to be used in the first argument of the Cconnect()> method. An example of this might be scanning the F<$HOME/.odbcini> file on Unix for ODBC data sources (DSNs). As a trivial example, consider a fixed list of data sources: sub data_sources { my($drh, $attr) = @_; my(@list) = (); # You need more sophisticated code than this to set @list... push @list, "dbi:Driver:abc"; push @list, "dbi:Driver:def"; push @list, "dbi:Driver:ghi"; # End of code to set @list return @list; } =head4 The disconnect_all() method If you need to release any resources when the driver is unloaded, you can provide a disconnect_all method. =head4 Other driver handle methods If you need any other driver handle methods, they can follow here. =head4 Error handling It is quite likely that something fails in the connect method. With B for example, you might catch an error when setting the current directory to something not existent by using the (driver-specific) I attribute. To report an error, you use the C method: $h->set_err($err, $errmsg, $state); This will ensure that the error is recorded correctly and that I and I etc are handled correctly. Typically you'll always use the method instance, aka your method's first argument. As C always returns C your error handling code can usually be simplified to something like this: return $h->set_err($err, $errmsg, $state) if ...; =head3 The DBD::Driver::db package package DBD::Driver::db; # ====== DATABASE ====== $DBD::Driver::db::imp_data_size = 0; =head4 The statement handle constructor There's nothing much new in the statement handle constructor, which is the C method: sub prepare { my ($dbh, $statement, @attribs) = @_; # create a 'blank' sth my ($outer, $sth) = DBI::_new_sth($dbh, { Statement => $statement }); $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//)); $sth->{drv_params} = []; return $outer; } This is still the same -- check the arguments and call the super class constructor C. Again, in scalar context, only the outer handle is returned. The I attribute should be cached as shown. Note the prefix I in the attribute names: it is required that all your private attributes use a lowercase prefix unique to your driver. As mentioned earlier in this document, the B contains a registry of known driver prefixes and may one day warn about unknown attributes that don't have a registered prefix. Note that we parse the statement here in order to set the attribute I. The technique illustrated is not very reliable; it can be confused by question marks appearing in quoted strings, delimited identifiers or in SQL comments that are part of the SQL statement. We could set I in the C method instead because the B specification explicitly allows a driver to defer this, but then the user could not call C. =head4 Transaction handling Pure Perl drivers will rarely support transactions. Thus your C and C 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 B that do nothing except return C. The B's default C method can be used by inheritance. =head4 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 B will handle most attributes for you, in particular attributes like I or I. All you have to do is handle your driver's private attributes and any attributes, like I and I, that the B 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/^drv_/) { # Handle only our private attributes here # Note that we could trigger arbitrary actions. # Ideally we should warn about 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/^drv_/) { # 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 B 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 C and C methods unless you need extra logic/checks, beyond getting or setting the value. Unless your driver documentation indicates otherwise, the return value of the C method is unspecified and the caller shouldn't use that value. =head4 Other database handle methods As with the driver package, other database handle methods may follow here. In particular you should consider a (possibly empty) C method and possibly a C method if B's default isn't correct for you. You may also need the C and C methods, as described elsewhere in this document. Where reasonable use C<$h-ESUPER::foo()> to call the B's method in some or all cases and just wrap your custom behavior around that. If you want to use private trace flags you'll probably want to be able to set them by name. To do that you'll need to define a C method (note that's "parse_trace_flag", singular, not "parse_trace_flags", plural). sub parse_trace_flag { my ($h, $name) = @_; return 0x01000000 if $name eq 'foo'; return 0x02000000 if $name eq 'bar'; return 0x04000000 if $name eq 'baz'; return 0x08000000 if $name eq 'boo'; return 0x10000000 if $name eq 'bop'; return $h->SUPER::parse_trace_flag($name); } All private flag names must be lowercase, and all private flags must be in the top 8 of the 32 bits. =head3 The DBD::Driver::st package This package follows the same pattern the others do: package DBD::Driver::st; $DBD::Driver::st::imp_data_size = 0; =head4 The execute() and bind_param() methods This is perhaps the most difficult method because we have to consider parameter bindings here. In addition to that, there are a number of statement attributes which must be set for inherited B methods to function correctly (see L below). We present a simplified implementation by using the I attribute from above: 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->{drv_params}; $params->[$pNum-1] = $val; 1; } sub execute { my ($sth, @bind_values) = @_; # start of by finishing any previous execution if still active $sth->finish if $sth->FETCH('Active'); my $params = (@bind_values) ? \@bind_values : $sth->{drv_params}; my $numParam = $sth->FETCH('NUM_OF_PARAMS'); return $sth->set_err($DBI::stderr, "Wrong number of parameters") if @$params != $numParam; my $statement = $sth->{'Statement'}; for (my $i = 0; $i < $numParam; $i++) { $statement =~ s/?/$params->[$i]/; # XXX doesn't deal with quoting etc! } # Do anything ... we assume that an array ref of rows is # created and store it: $sth->{'drv_data'} = $data; $sth->{'drv_rows'} = @$data; # number of rows $sth->STORE('NUM_OF_FIELDS') = $numFields; $sth->{Active} = 1; @$data || '0E0'; } There are a number of things you should note here. We initialize the I and I attributes here, because they are essential for C to work. We use attribute C<$sth-E{Statement}> which we created within C. The attribute C<$sth-E{Database}>, which is nothing else than the I, was automatically created by B. Finally, note that (as specified in the B specification) we return the string C<'0E0'> instead of the number 0, so that the result tests true but equal to zero. $sth->execute() or die $sth->errstr; =head4 The execute_array(), execute_for_fetch() and bind_param_array() methods In general, DBD's only need to implement C and C. DBI's default C will invoke the DBD's C as needed. The following sequence describes the interaction between DBI C and a DBD's C: =over =item 1 App calls C<$sth-Eexecute_array(\%attrs, @array_of_arrays)> =item 2 If C<@array_of_arrays> was specified, DBI processes C<@array_of_arrays> by calling DBD's C. Alternately, App may have directly called C =item 3 DBD validates and binds each array =item 4 DBI retrieves the validated param arrays from DBD's ParamArray attribute =item 5 DBI calls DBD's C, where C<&$fetch_tuple_sub> is a closure to iterate over the returned ParamArray values, and C<\@tuple_status> is an array to receive the disposition status of each tuple. =item 6 DBD iteratively calls C<&$fetch_tuple_sub> to retrieve parameter tuples to be added to its bulk database operation/request. =item 7 when DBD reaches the limit of tuples it can handle in a single database operation/request, or the C<&$fetch_tuple_sub> indicates no more tuples by returning undef, the DBD executes the bulk operation, and reports the disposition of each tuple in \@tuple_status. =item 8 DBD repeats steps 6 and 7 until all tuples are processed. =back E.g., here's the essence of L's execute_for_fetch: while (1) { my @tuple_batch; for (my $i = 0; $i < $batch_size; $i++) { push @tuple_batch, [ @{$fetch_tuple_sub->() || last} ]; } last unless @tuple_batch; my $res = ora_execute_array($sth, \@tuple_batch, scalar(@tuple_batch), $tuple_batch_status); push @$tuple_status, @$tuple_batch_status; } Note that DBI's default execute_array()/execute_for_fetch() implementation requires the use of positional (i.e., '?') placeholders. Drivers which B named placeholders must either emulate positional placeholders (e.g., see L), or must implement their own execute_array()/execute_for_fetch() methods to properly sequence bound parameter arrays. =head4 Fetching data Only one method needs to be written for fetching data, C. The other methods, C, C, etc, as well as the database handle's C methods are part of B, and call C as necessary. sub fetchrow_arrayref { my ($sth) = @_; my $data = $sth->{drv_data}; my $row = shift @$data; if (!$row) { $sth->STORE(Active => 0); # mark as no longer active return undef; } if ($sth->FETCH('ChopBlanks')) { map { $_ =~ s/\s+$//; } @$row; } return $sth->_set_fbav($row); } *fetch = \&fetchrow_arrayref; # required alias for fetchrow_arrayref Note the use of the method C<_set_fbav()> -- this is required so that C and C work. If an error occurs which leaves the I<$sth> in a state where remaining rows can't be fetched then I should be turned off before the method returns. The C method for this driver can be implemented like this: sub rows { shift->{drv_rows} } because it knows in advance how many rows it has fetched. Alternatively you could delete that method and so fallback to the B's own method which does the right thing based on the number of calls to C<_set_fbav()>. =head4 The more_results method If your driver doesn't support multiple result sets, then don't even implement this method. Otherwise, this method needs to get the statement handle ready to fetch results from the next result set, if there is one. Typically you'd start with: $sth->finish; then you should delete all the attributes from the attribute cache that may no longer be relevant for the new result set: delete $sth->{$_} for qw(NAME TYPE PRECISION SCALE ...); for drivers written in C use: hv_delete((HV*)SvRV(sth), "NAME", 4, G_DISCARD); hv_delete((HV*)SvRV(sth), "NULLABLE", 8, G_DISCARD); hv_delete((HV*)SvRV(sth), "NUM_OF_FIELDS", 13, G_DISCARD); hv_delete((HV*)SvRV(sth), "PRECISION", 9, G_DISCARD); hv_delete((HV*)SvRV(sth), "SCALE", 5, G_DISCARD); hv_delete((HV*)SvRV(sth), "TYPE", 4, G_DISCARD); Don't forget to also delete, or update, any driver-private attributes that may not be correct for the next resultset. The NUM_OF_FIELDS attribute is a special case. It should be set using STORE: $sth->STORE(NUM_OF_FIELDS => 0); /* for DBI <= 1.53 */ $sth->STORE(NUM_OF_FIELDS => $new_value); for drivers written in C use this incantation: /* Adjust NUM_OF_FIELDS - which also adjusts the row buffer size */ DBIc_NUM_FIELDS(imp_sth) = 0; /* for DBI <= 1.53 */ DBIc_STATE(imp_xxh)->set_attr_k(sth, sv_2mortal(newSVpvn("NUM_OF_FIELDS",13)), 0, sv_2mortal(newSViv(mysql_num_fields(imp_sth->result))) ); For DBI versions prior to 1.54 you'll also need to explicitly adjust the number of elements in the row buffer array (C) to match the new result set. Fill any new values with newSV(0) not &sv_undef. Alternatively you could free DBIc_FIELDS_AV(imp_sth) and set it to null, but that would mean bind_columns() woudn't work across result sets. =head4 Statement attributes The main difference between I and I attributes is, that you should implement a lot of attributes here that are required by the B, such as I, I, I, etc. See L for a complete list. Pay attention to attributes which are marked as read only, such as I. These attributes can only be set the first time a statement is executed. If a statement is prepared, then executed multiple times, warnings may be generated. You can protect against these warnings, and prevent the recalculation of attributes which might be expensive to calculate (such as the I and I attributes): my $storedNumParams = $sth->FETCH('NUM_OF_PARAMS'); if (!defined $storedNumParams or $storedNumFields < 0) { $sth->STORE('NUM_OF_PARAMS') = $numParams; # Set other useful attributes that only need to be set once # for a statement, like $sth->{NAME} and $sth->{TYPE} } One particularly important attribute to set correctly (mentioned in L is I. Many B methods, including C, depend on this attribute. Besides that the C and C methods are mainly the same as above for I's. =head4 Other statement methods A trivial C method to discard stored data, reset any attributes (such as I) and do C<$sth-ESUPER::finish()>. If you've defined a C method in B<::db> you'll also want it in B<::st>, so just alias it in: *parse_trace_flag = \&DBD::foo:db::parse_trace_flag; And perhaps some other methods that are not part of the B specification, in particular to make metadata available. Remember that they must have names that begin with your drivers registered prefix so they can be installed using C. If C is called on a statement handle that's still active (C<$sth-E{Active}> is true) then it should effectively call C. sub DESTROY { my $sth = shift; $sth->finish if $sth->FETCH('Active'); } =head2 Tests The test process should conform as closely as possibly to the Perl standard test harness. In particular, most (all) of the tests should be run in the F sub-directory, and should simply produce an C when run under C. 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. For example, the B 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: some of the tests are for databases without transaction logs; others are for databases with a transaction log; some versions of the server have support for blobs, or stored procedures, or user-defined data types, and others do not. When a complete file of tests must be skipped, you can provide a reason in a pseudo-comment: if ($no_transactions_available) { print "1..0 # Skip: No transactions available\n"; exit 0; } Consider downloading the B code and look at the code in F which is used throughout the B tests in the F sub-directory. =head1 CREATING A C/XS DRIVER Please also see the section under L regarding the creation of the F. 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 B written by Tim Bunce, who is also the author of the B package. The B module is a good example of a driver implemented around a C-level API. Nowadays it it seems better to base on B, 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 B digs deeper into the Oracle 8 OCI interface it'll get even more hairy than it is now.) The B driver is one driver implemented using embedded SQL instead of a function-based API. B may also be worth a look. =head2 C/XS version of Driver.pm A lot of the code in the F file is very similar to the code for pure Perl modules - see above. However, there are also some subtle (and not so subtle) differences, including: =over 8 =item * The variables I<$DBD::Driver::{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 C, C, C, C and the C and C methods. =item * Other methods are still part of F, but have callbacks to the XS code. =item * If the driver-specific parts of the I structure need to be formally initialized (which does not seem to be a common requirement), then you need to add a call to an appropriate XS function in the driver method of C, and you define the corresponding function in F, and you define the C code in F and the prototype in F. For example, B has such a requirement, and adds the following call after the call to C<_new_drh()> in F: DBD::Informix::dr::driver_init($drh); and the following code in F: # Initialize the DBD::Informix driver data structure void driver_init(drh) SV *drh CODE: ST(0) = dbd_ix_dr_driver_init(drh) ? &sv_yes : &sv_no; and the code in F declares: extern int dbd_ix_dr_driver_init(SV *drh); and the code in F (equivalent to F) defines: /* Formally initialize the DBD::Informix driver structure */ int dbd_ix_dr_driver(SV *drh) { D_imp_drh(drh); imp_drh->n_connections = 0; /* No active connections */ imp_drh->current_connection = 0; /* No current connection */ imp_drh->multipleconnections = (ESQLC_VERSION >= 600) ? True : False; dbd_ix_link_newhead(&imp_drh->head); /* Empty linked list of connections */ return 1; } B has a similar requirement but gets around it by checking whether the private data part of the driver handle is all zeroed out, rather than add extra functions. =back Now let's take a closer look at an excerpt from F (revised heavily to remove idiosyncrasies) as an example, ignoring things that were already discussed for pure Perl drivers. =head3 The connect method The connect method is the database handle constructor. You could write either of two versions of this method: either one which takes connection attributes (new code) and one which ignores them (old code only). If you ignore the connection attributes, then you omit all mention of the I<$auth> variable (which is a reference to a hash of attributes), and the XS system manages the differences for you. 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. my $dbh = DBI::_new_dbh($drh, { 'Name' => $dbname, }) or return undef; # Call the driver-specific function _login in Driver.xs file which # calls the DBMS-specific function(s) to connect to the database, # and populate internal handle data. DBD::Driver::db::_login($dbh, $dbname, $user, $auth, $attr) or return undef; $dbh; } This is mostly the same as in the pure Perl case, the exception being the use of the private C<_login()> callback, which is the function that will really connect to the database. It is implemented in F (you should not implement it) and calls C from F. See below for details. *FIX ME* Discuss removing attributes from hash reference as an optimization to skip later calls to $dbh->STORE made by DBI->connect. *FIX ME* Discuss removing attributes in Perl code. *FIX ME* Discuss removing attributes in C code. =head3 The disconnect_all method *FIX ME* T.B.S =head3 The data_sources method If your C method can be implemented in pure Perl, then do so because it is easier than doing it in XS code (see the section above for pure Perl drivers). If your C method must call onto compiled functions, then you will need to define I in your F file, which will trigger F (in B v1.33 or greater) to generate the XS code that calls your actual C function (see the discussion below for details) and you do not code anything in F to handle it. =head3 The prepare method The prepare method is the statement handle constructor, and most of it is not new. Like the C method, it now has a C callback: package DBD::Driver::db; # ====== DATABASE ====== use strict; sub prepare { my ($dbh, $statement, $attribs) = @_; # create a 'blank' sth my $sth = DBI::_new_sth($dbh, { 'Statement' => $statement, }) or return undef; # Call the driver-specific function _prepare in Driver.xs file # which calls the DBMS-specific function(s) to prepare a statement # and populate internal handle data. DBD::Driver::st::_prepare($sth, $statement, $attribs) or return undef; $sth; } =head3 The execute method *FIX ME* T.B.S =head3 The fetchrow_arrayref method *FIX ME* T.B.S =head3 Other methods? *FIX ME* T.B.S =head2 Driver.xs F should look something like this: #include "Driver.h" DBISTATE_DECLARE; INCLUDE: Driver.xsi MODULE = DBD::Driver PACKAGE = DBD::Driver::dr /* Non-standard drh XS methods following here, if any. */ /* If none (the usual case), omit the MODULE line above too. */ 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 F here: B 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 F, and this is what you have to implement. You need to set up an extra routine if your driver needs to export constants of its own, analogous to the SQL types available when you say: use DBI qw(:sql_types); *FIX ME* T.B.S =head2 Driver.h F is very simple and the operational contents should look like this: #ifndef DRIVER_H_INCLUDED #define DRIVER_H_INCLUDED #define NEED_DBIXS_VERSION 93 /* 93 for DBI versions 1.00 to 1.51+ */ #define PERL_NO_GET_CONTEXT /* if used require DBI 1.51+ */ #include /* installed by the DBI module */ #include "dbdimp.h" #include "dbivport.h" /* see below */ #include /* installed by the DBI module */ #endif /* DRIVER_H_INCLUDED */ The F header defines most of the interesting information that the writer of a driver needs. The file F header provides prototype declarations for the C functions that you might decide to implement. Note that you should normally only define one of C and C unless you are intent on supporting really old versions of B (prior to B 1.06) as well as modern versions. The only standard, B-mandated functions that you need write are those specified in the F header. You might also add extra driver-specific functions in F. The F file should be I from the latest B release into your distribution each time you modify your driver. Its job is to allow you to enhance your code to work with the latest B API while still allowing your driver to be compiled and used with older versions of the B (for example, when the C macro was added to B 1.41, an emulation of it was added to F). This makes users happy and your life easier. Always read the notes in F to check for any limitations in the emulation that you should be aware of. With B v1.51 or better I recommend that the driver defines I before F is included. This can significantly improve efficiency when running under a thread enabled perl. (Remember that the standard perl in most Linux distributions is built with threads enabled. So is ActiveState perl for Windows, and perl built for Apache mod_perl2.) If you do this there are some things to keep in mind: =over 4 =item * If I is defined, then every function that calls the Perl API will need to start out with a C declaration. =item * You'll know which functions need this, because the C compiler will complain that the undeclared identifier C is used if I the perl you are using to develop and test your driver has threads enabled. =item * If you don't remember to test with a thread-enabled perl before making a release it's likely that you'll get failure reports from users who are. =item * For driver private functions it is possible to gain even more efficiency by replacing C with C prepended to the parameter list and then C prepended to the argument list where the function is called. =back See L for additional information about I. =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 C to database specific names like C. 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 C function is not passed the attribute hash. Since B v1.06, if a C macro is defined (for a function with 6 arguments), it will be used instead with the attribute hash passed as the sixth argument. People used to just pick Oracle's F 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 hell when I had to separate B specific parts, Oracle specific parts, mSQL specific parts and mysql specific parts in B's I and I. (B was a port of B which was based on B.) [Seconded, based on the experience taking B apart, even though the version inherited in 1996 was only based on B.] 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 keep an eye on 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 drv_dr_init #define dbd_db_login6 drv_db_login #define dbd_db_do drv_db_do ... many more here ... These structures implement your private part of the handles. You I to use the name C and the first field I be of type I and I be called C. You should never access these fields directly, except by using the I macros below. =head2 Implementation source dbdimp.c Conventionally, F is the main implementation file (but B calls the file F). This section includes a short note on each function that is used in the F template and thus I to be implemented. Of course, you will probably also need to implement other support functions, which should usually be file static if they are placed in F. If they are placed in other files, you need to list those files in F (and F) to handle them correctly. It is wise to adhere to a namespace convention for your functions to avoid conflicts. For example, for a driver with prefix I, you might call externally visible functions I. You should also avoid non-constant global variables as much as possible to improve the support for threading. Since Perl requires support for function prototypes (ANSI or ISO or Standard C), you should write your code using function prototypes too. It is possible to use either the unmapped names such as C or the mapped names such as C in the F file. B uses the mapped names which makes it easier to identify where to look for linkage problems at runtime (which will report errors using the mapped names). Most other drivers, and in particular B, use the unmapped names in the source code which makes it a little easier to compare code between drivers and eases discussions on the I mailing list. The majority of the code fragments here will use the unmapped names. Ultimately, you should provide implementations for most fo the functions listed in the F header. The exceptions are optional functions (such as C) and those functions with alternative signatures, such as C and I. Then you should only implement one of the alternatives, and generally the newer one of the alternatives. =head3 The dbd_init method #include "Driver.h" DBISTATE_DECLARE; void dbd_init(dbistate_t* dbistate) { DBISTATE_INIT; /* Initialize the DBI macros */ } The C function will be called when your driver is first loaded; the bootstrap command in C triggers this, and the call is generated in the I section of F. These statements are needed to allow your driver to use the B macros. They will include your private header file F in turn. Note that I requires the name of the argument to C to be called C. =head3 The dbd_drv_error method You need a function to record errors so B can access them properly. You can call it whatever you like, but we'll call it C here. The argument list depends on your database software; different systems provide different ways to get at error information. static void dbd_drv_error(SV *h, int rc, const 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. To record the error correctly, equivalent to the C method, use one of the C or C macros, which were added in B 1.41: DBIh_SET_ERR_SV(h, imp_xxh, err, errstr, state, method); DBIh_SET_ERR_CHAR(h, imp_xxh, err_c, err_i, errstr, state, method); For C the I, I, I, and I parameters are C. For C the I, I, I, I parameters are C. The I parameter is an C that's used instead of I if I is C. The I parameter can be ignored. The C macro is usually the simplest to use when you just have an integer error code and an error message string: DBIh_SET_ERR_CHAR(h, imp_xxh, Nullch, rc, what, Nullch, Nullch); As you can see, any parameters that aren't relevant to you can be C. To make drivers compatible with B < 1.41 you should be using F as described in L above. The (obsolete) macros such as C should be removed from drivers. The names C and C, which were used in previous versions of this document, should be replaced with the C macro. The name C, which was also used in previous versions of this document, should be replaced by C. Your code should not call the C Cstdio.hE> I/O functions; you should use C as shown: if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar %s: %s\n", foo, neatsvpv(errstr,0)); That's the first time we see how tracing works within a B driver. Make use of this as often as you can, but don't output anything at a trace level less than 3. Levels 1 and 2 are reserved for the B. You can define up to 8 private trace flags using the top 8 bits of C, that is: C<0xFF000000>. See the C method elsewhere in this document. =head3 The dbd_dr_data_sources method This method is optional; the support for it was added in B v1.33. As noted in the discussion of F, if the data sources can be determined by pure Perl code, do it that way. If, as in B, the information is obtained by a C function call, then you need to define a function that matches the prototype: extern AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attrs); An outline implementation for B follows, assuming that the C function call shown will return up to 100 databases names, with the pointers to each name in the array dbsname and the name strings themselves being stores in dbsarea. AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attr) { int ndbs; int i; char *dbsname[100]; char dbsarea[10000]; AV *av = Nullav; if (sqgetdbs(&ndbs, dbsname, 100, dbsarea, sizeof(dbsarea)) == 0) { av = NewAV(); av_extend(av, (I32)ndbs); sv_2mortal((SV *)av); for (i = 0; i < ndbs; i++) av_store(av, i, newSVpvf("dbi:Informix:%s", dbsname[i])); } return(av); } The actual B implementation has a number of extra lines of code, logs function entry and exit, reports the error from C, and uses C<#define>'d constants for the array sizes. =head3 The dbd_db_login6 method 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 C above. The arguments I, I, I and I correspond to the arguments of the driver handle's C method. You will quite often use database specific attributes here, that are specified in the DSN. I recommend you parse the DSN (using Perl) within the C method and pass the segments of the DSN via the attributes parameter through C<_login()> to C. Here's how you fetch them; as an example we use I attribute, which can be up to 12 characters long excluding null terminator: 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"; } Note that you can also obtain standard attributes such as I and I from the attributes parameter, using C for integer attributes. If, for example, your database does not support transactions but I is set off (requesting transaction support), then you can emulate a 'failure to connect'. Now you should really connect to the database. In general, if the connection fails, it is best to ensure that all allocated resources are released so that the handle does not need to be destroyed separately. If you are successful (and possibly 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 I structure and that the implementors private C 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 C function should be called before the handle is destroyed. Note that if you do need to fail, you should report errors via the I or I rather than via I or I because I will be destroyed by the failure, so errors recorded in that handle will not be visible to B, and hence not the user either. Note too, that the function is passed I and I, and there is a macro C which can recover the I from the I. However, there is no B macro to provide you with the I given either the I or the I or the I (and there's no way to recover the I given just the I). This suggests that, despite the above notes about C taking an C, it may be better to have two error routines, one taking I and one taking I instead. With care, you can factor most of the formatting code out so that these are small routines calling a common error formatter. See the code in B 1.05.00 for more information. The C function should return I for success, I otherwise. Drivers implemented long ago may define the five-argument function C instead of C. The missing argument is the attributes. There are ways to work around the missing attributes, but they are ungainly; it is much better to use the 6-argument form. =head3 The dbd_db_commit and dbd_db_rollback methods 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 I for success, I for error. The arguments I and I are the same as for C above; I will omit describing them in what follows, as they appear always. These functions should return I for success, I otherwise. =head3 The dbd_db_disconnect method This is your private part of the C method. Any I with the I flag on must be disconnected. (Note that you have to set it in C above.) int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh); The database handle will return I for success, I otherwise. In any case it should do a: DBIc_ACTIVE_off(imp_dbh); before returning so B knows that C was executed. Note that there's nothing to stop a I being I while it still have active children. If your database API reacts badly to trying to use an I in this situation then you'll need to add code like this to all I methods: if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth))) return 0; Alternatively, you can add code to your driver to keep explicit track of the statement handles that exist for each database handle and arrange to destroy those handles before disconnecting from the database. There is code to do this in B. Similar comments apply to the driver handle keeping track of all the database handles. Note that the code which destroys the subordinate handles should only release the associated database resources and mark the handles inactive; it does not attempt to free the actual handle structures. This function should return I for success, I otherwise, but it is not clear what anything can do about a failure. =head3 The dbd_db_discon_all method 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'. This function should return I for success, I otherwise, but it is not clear what anything can do about a failure. =head3 The dbd_db_destroy method This is your private part of the database handle destructor. Any I with the I flag on must be destroyed, so that you can safely free resources. (Note that you have to set it in C above.) void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh) { DBIc_IMPSET_off(imp_dbh); } The B F code will have called C for you, if the handle is still 'active', before calling C. Before returning the function must switch I to off, so B knows that the destructor was called. A B handle doesn't keep references to its children. But children do keep references to their parents. So a database handle won't be C'd until all its children have been C'd. =head3 The dbd_db_STORE_attrib method 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 B attributes here: leave this to B. (There are two exceptions, I and I, which you should care about.) The return value is I if you have handled the attribute or I otherwise. If you are handling an attribute and something fails, you should call C, so B can raise exceptions, if desired. If C 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 C returns, but there are examples where even the B specification expects that you C. (See the I method in L.) If you have to store attributes, you should either use your private data structure I, the handle hash (via C<(HV*)SvRV(dbh)>), or use the private I. 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 I is an additional C attached to the handle. You could think of it as an unnamed handle attribute. It's not normally used. =head3 The dbd_db_FETCH_attrib method This is the counterpart of C, 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 C with the value. Note that you should normally execute C, if you return a nonconstant value. (Constant values are C<&sv_undef>, C<&sv_no> and C<&sv_yes>.) Note, that B implements a caching algorithm for attribute values. If you think, that an attribute may be fetched, you store it in the I itself: if (cacheit) /* cache value for later DBI 'quick' fetch? */ hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0); =head3 The dbd_st_prepare method This is the private part of the C method. Note that you B really execute the statement here. You may, however, 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 C code that set the I attribute on the handle. This attribute can then be used by C. If the driver supports placeholders then the I attribute must be set correctly by C: DBIc_NUM_PARAMS(imp_sth) = ... If you can, you should also setup attributes like I, I, etc. here, but B doesn't require that - they can be deferred until execute() is called. However, if you do, document it. In any case you should set the I flag, as you did in C above: DBIc_IMPSET_on(imp_sth); =head3 The dbd_st_execute method 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 a statement may be executed repeatedly. Also, you should not expect that C will be called between two executions, so you might need code, like the following, near the start of the function: if (DBIc_ACTIVE(imp_sth)) dbd_st_finish(h, imp_sth); If your driver supports the 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); /* It is 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 to really execute the statement. Note that you must set the attributes I, I, etc when the statement is successfully executed if the driver has not already done so: they may be used even before a potential C. In particular you have to tell B the number of fields that the statement has, because it will be used by B 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 I flag only be set for C