1DBI::DBD(3)           User Contributed Perl Documentation          DBI::DBD(3)
2
3
4

NAME

6       DBI::DBD - Perl DBI Database Driver Writer's Guide
7

SYNOPSIS

9         perldoc DBI::DBD
10
11   Version and volatility
12       This document is still a minimal draft which is in need of further
13       work.
14
15       Please read the DBI documentation first and fully.  Then look at the
16       implementation of some high-profile and regularly maintained drivers
17       like DBD::Oracle, DBD::ODBC, DBD::Pg etc. (Those are no no particular
18       order.)
19
20       Then reread the DBI specification and the code of those drivers again
21       as you're reading this. It'll help.  Where this document and the driver
22       code differ it's likely that the driver code is more correct,
23       especially if multiple drivers do the same thing.
24
25       This document is a patchwork of contributions from various authors.
26       More contributions (preferably as patches) are very welcome.
27

DESCRIPTION

29       This document is primarily intended to help people writing new database
30       drivers for the Perl Database Interface (Perl DBI).  It may also help
31       others interested in discovering why the internals of a DBD driver are
32       written the way they are.
33
34       This is a guide.  Few (if any) of the statements in it are completely
35       authoritative under all possible circumstances.  This means you will
36       need to use judgement in applying the guidelines in this document.  If
37       in any doubt at all, please do contact the dbi-dev mailing list
38       (details given below) where Tim Bunce and other driver authors can
39       help.
40

CREATING A NEW DRIVER

42       The first rule for creating a new database driver for the Perl DBI is
43       very simple: DON'T!
44
45       There is usually a driver already available for the database you want
46       to use, almost regardless of which database you choose. Very often, the
47       database will provide an ODBC driver interface, so you can often use
48       DBD::ODBC to access the database. This is typically less convenient on
49       a Unix box than on a Microsoft Windows box, but there are numerous
50       options for ODBC driver managers on Unix too, and very often the ODBC
51       driver is provided by the database supplier.
52
53       Before deciding that you need to write a driver, do your homework to
54       ensure that you are not wasting your energies.
55
56       [As of December 2002, the consensus is that if you need an ODBC driver
57       manager on Unix, then the unixODBC driver (available from
58       <http://www.unixodbc.org/>) is the way to go.]
59
60       The second rule for creating a new database driver for the Perl DBI is
61       also very simple: Don't -- get someone else to do it for you!
62
63       Nevertheless, there are occasions when it is necessary to write a new
64       driver, often to use a proprietary language or API to access the
65       database more swiftly, or more comprehensively, than an ODBC driver
66       can.  Then you should read this document very carefully, but with a
67       suitably sceptical eye.
68
69       If there is something in here that does not make any sense, question
70       it.  You might be right that the information is bogus, but don't come
71       to that conclusion too quickly.
72
73   URLs and mailing lists
74       The primary web-site for locating DBI software and information is
75
76         http://dbi.perl.org/
77
78       There are two main and one auxiliary mailing lists for people working
79       with DBI.  The primary lists are dbi-users@perl.org for general users
80       of DBI and DBD drivers, and dbi-dev@perl.org mainly for DBD driver
81       writers (don't join the dbi-dev list unless you have a good reason).
82       The auxiliary list is dbi-announce@perl.org for announcing new releases
83       of DBI or DBD drivers.
84
85       You can join these lists by accessing the web-site
86       <http://dbi.perl.org/>.  The lists are closed so you cannot send email
87       to any of the lists unless you join the list first.
88
89       You should also consider monitoring the comp.lang.perl.* newsgroups,
90       especially comp.lang.perl.modules.
91
92   The Cheetah book
93       The definitive book on Perl DBI is the Cheetah book, so called because
94       of the picture on the cover. Its proper title is 'Programming the Perl
95       DBI: Database programming with Perl' by Alligator Descartes and Tim
96       Bunce, published by O'Reilly Associates, February 2000, ISBN
97       1-56592-699-4. Buy it now if you have not already done so, and read it.
98
99   Locating drivers
100       Before writing a new driver, it is in your interests to find out
101       whether there already is a driver for your database.  If there is such
102       a driver, it would be much easier to make use of it than to write your
103       own!
104
105       The primary web-site for locating Perl software is
106       <http://search.cpan.org/>.  You should look under the various modules
107       listings for the software you are after. For example:
108
109         http://search.cpan.org/modlist/Database_Interfaces
110
111       Follow the DBD:: and DBIx:: links at the top to see those subsets.
112
113       See the DBI docs for information on DBI web sites and mailing lists.
114
115   Registering a new driver
116       Before going through any official registration process, you will need
117       to establish that there is no driver already in the works. You'll do
118       that by asking the DBI mailing lists whether there is such a driver
119       available, or whether anybody is working on one.
120
121       When you get the go ahead, you will need to establish the name of the
122       driver and a prefix for the driver. Typically, the name is based on the
123       name of the database software it uses, and the prefix is a contraction
124       of that. Hence, DBD::Oracle has the name Oracle and the prefix 'ora_'.
125       The prefix must be lowercase and contain no underscores other than the
126       one at the end.
127
128       This information will be recorded in the DBI module. Apart from
129       documentation purposes, registration is a prerequisite for installing
130       private methods.
131
132       If you are writing a driver which will not be distributed on CPAN, then
133       you should choose a prefix beginning with 'x_', to avoid potential
134       prefix collisions with drivers registered in the future. Thus, if you
135       wrote a non-CPAN distributed driver called DBD::CustomDB, the prefix
136       might be 'x_cdb_'.
137
138       This document assumes you are writing a driver called DBD::Driver, and
139       that the prefix 'drv_' is assigned to the driver.
140
141   Two styles of database driver
142       There are two distinct styles of database driver that can be written to
143       work with the Perl DBI.
144
145       Your driver can be written in pure Perl, requiring no C compiler.  When
146       feasible, this is the best solution, but most databases are not written
147       in such a way that this can be done. Some examples of pure Perl drivers
148       are DBD::File and DBD::CSV.
149
150       Alternatively, and most commonly, your driver will need to use some C
151       code to gain access to the database. This will be classified as a C/XS
152       driver.
153
154   What code will you write?
155       There are a number of files that need to be written for either a pure
156       Perl driver or a C/XS driver. There are no extra files needed only by a
157       pure Perl driver, but there are several extra files needed only by a
158       C/XS driver.
159
160       Files common to pure Perl and C/XS drivers
161
162       Assuming that your driver is called DBD::Driver, these files are:
163
164       ·   Makefile.PL
165
166       ·   META.yml
167
168       ·   README
169
170       ·   MANIFEST
171
172       ·   Driver.pm
173
174       ·   lib/Bundle/DBD/Driver.pm
175
176       ·   lib/DBD/Driver/Summary.pm
177
178       ·   t/*.t
179
180       The first four files are mandatory. Makefile.PL is used to control how
181       the driver is built and installed. The README file tells people who
182       download the file about how to build the module and any prerequisite
183       software that must be installed. The MANIFEST file is used by the
184       standard Perl module distribution mechanism. It lists all the source
185       files that need to be distributed with your module. Driver.pm is what
186       is loaded by the DBI code; it contains the methods peculiar to your
187       driver.
188
189       Although the META.yml file is not required you are advised to create
190       one. Of particular importance are the build_requires and
191       configure_requires attributes which newer CPAN modules understand.  You
192       use these to tell the CPAN module (and CPANPLUS) that your build and
193       configure mechanisms require DBI. The best reference for META.yml (at
194       the time of writing) is
195       <http://module-build.sourceforge.net/META-spec-v1.4.html>. You can find
196       a reasonable example of a META.yml in DBD::ODBC.
197
198       The lib/Bundle/DBD/Driver.pm file allows you to specify other Perl
199       modules on which yours depends in a format that allows someone to type
200       a simple command and ensure that all the pre-requisites are in place as
201       well as building your driver.
202
203       The lib/DBD/Driver/Summary.pm file contains (an updated version of) the
204       information that was included - or that would have been included - in
205       the appendices of the Cheetah book as a summary of the abilities of
206       your driver and the associated database.
207
208       The files in the t subdirectory are unit tests for your driver.  You
209       should write your tests as stringently as possible, while taking into
210       account the diversity of installations that you can encounter:
211
212       ·   Your tests should not casually modify operational databases.
213
214       ·   You should never damage existing tables in a database.
215
216       ·   You should code your tests to use a constrained name space within
217           the database. For example, the tables (and all other named objects)
218           that are created could all begin with 'dbd_drv_'.
219
220       ·   At the end of a test run, there should be no testing objects left
221           behind in the database.
222
223       ·   If you create any databases, you should remove them.
224
225       ·   If your database supports temporary tables that are automatically
226           removed at the end of a session, then exploit them as often as
227           possible.
228
229       ·   Try to make your tests independent of each other. If you have a
230           test t/t11dowhat.t that depends upon the successful running of
231           t/t10thingamy.t, people cannot run the single test case
232           t/t11dowhat.t. Further, running t/t11dowhat.t twice in a row is
233           likely to fail (at least, if t/t11dowhat.t modifies the database at
234           all) because the database at the start of the second run is not
235           what you saw at the start of the first run.
236
237       ·   Document in your README file what you do, and what privileges
238           people need to do it.
239
240       ·   You can, and probably should, sequence your tests by including a
241           test number before an abbreviated version of the test name; the
242           tests are run in the order in which the names are expanded by
243           shell-style globbing.
244
245       ·   It is in your interests to ensure that your tests work as widely as
246           possible.
247
248       Many drivers also install sub-modules DBD::Driver::SubModule for any of
249       a variety of different reasons, such as to support the metadata methods
250       (see the discussion of "METADATA METHODS" below). Such sub-modules are
251       conventionally stored in the directory lib/DBD/Driver. The module
252       itself would usually be in a file SubModule.pm. All such sub-modules
253       should themselves be version stamped (see the discussions far below).
254
255       Extra files needed by C/XS drivers
256
257       The software for a C/XS driver will typically contain at least four
258       extra files that are not relevant to a pure Perl driver.
259
260       ·   Driver.xs
261
262       ·   Driver.h
263
264       ·   dbdimp.h
265
266       ·   dbdimp.c
267
268       The Driver.xs file is used to generate C code that Perl can call to
269       gain access to the C functions you write that will, in turn, call down
270       onto your database software.
271
272       The Driver.h header is a stylized header that ensures you can access
273       the necessary Perl and DBI macros, types, and function declarations.
274
275       The dbdimp.h is used to specify which functions have been implemented
276       by your driver.
277
278       The dbdimp.c file is where you write the C code that does the real work
279       of translating between Perl-ish data types and what the database
280       expects to use and return.
281
282       There are some (mainly small, but very important) differences between
283       the contents of Makefile.PL and Driver.pm for pure Perl and C/XS
284       drivers, so those files are described both in the section on creating a
285       pure Perl driver and in the section on creating a C/XS driver.
286
287       Obviously, you can add extra source code files to the list.
288
289   Requirements on a driver and driver writer
290       To be remotely useful, your driver must be implemented in a format that
291       allows it to be distributed via CPAN, the Comprehensive Perl Archive
292       Network (<http://www.cpan.org/> and <http://search.cpan.org>).  Of
293       course, it is easier if you do not have to meet this criterion, but you
294       will not be able to ask for much help if you do not do so, and no-one
295       is likely to want to install your module if they have to learn a new
296       installation mechanism.
297

CREATING A PURE PERL DRIVER

299       Writing a pure Perl driver is surprisingly simple. However, there are
300       some problems you should be aware of. The best option is of course
301       picking up an existing driver and carefully modifying one method after
302       the other.
303
304       Also look carefully at DBD::AnyData and DBD::Template.
305
306       As an example we take a look at the DBD::File driver, a driver for
307       accessing plain files as tables, which is part of the DBD::CSV package.
308
309       The minimal set of files we have to implement are Makefile.PL, README,
310       MANIFEST and Driver.pm.
311
312   Pure Perl version of Makefile.PL
313       You typically start with writing Makefile.PL, a Makefile generator. The
314       contents of this file are described in detail in the
315       ExtUtils::MakeMaker man pages. It is definitely a good idea if you
316       start reading them. At least you should know about the variables
317       CONFIGURE, DEFINED, PM, DIR, EXE_FILES, INC, LIBS, LINKTYPE, NAME,
318       OPTIMIZE, PL_FILES, VERSION, VERSION_FROM, clean, depend, realclean
319       from the ExtUtils::MakeMaker man page: these are used in almost any
320       Makefile.PL.
321
322       Additionally read the section on Overriding MakeMaker Methods and the
323       descriptions of the distcheck, disttest and dist targets: They will
324       definitely be useful for you.
325
326       Of special importance for DBI drivers is the postamble method from the
327       ExtUtils::MM_Unix man page.
328
329       For Emacs users, I recommend the libscan method, which removes Emacs
330       backup files (file names which end with a tilde '~') from lists of
331       files.
332
333       Now an example, I use the word "Driver" wherever you should insert your
334       driver's name:
335
336         # -*- perl -*-
337
338         use ExtUtils::MakeMaker;
339
340         WriteMakefile(
341             dbd_edit_mm_attribs( {
342                 'NAME'         => 'DBD::Driver',
343                 'VERSION_FROM' => 'Driver.pm',
344                 'INC'          => '',
345                 'dist'         => { 'SUFFIX'   => '.gz',
346                                     'COMPRESS' => 'gzip -9f' },
347                 'realclean'    => { FILES => '*.xsi' },
348                 'PREREQ_PM'    => '1.03',
349                 'CONFIGURE'    => sub {
350                     eval {require DBI::DBD;};
351                     if ($@) {
352                         warn $@;
353                         exit 0;
354                     }
355                     my $dbi_arch_dir = dbd_dbi_arch_dir();
356                     if (exists($opts{INC})) {
357                         return {INC => "$opts{INC} -I$dbi_arch_dir"};
358                     } else {
359                         return {INC => "-I$dbi_arch_dir"};
360                     }
361                 }
362             },
363             { create_pp_tests => 1})
364         );
365
366         package MY;
367         sub postamble { return main::dbd_postamble(@_); }
368         sub libscan {
369             my ($self, $path) = @_;
370             ($path =~ m/\~$/) ? undef : $path;
371         }
372
373       Note the calls to "dbd_edit_mm_attribs()" and "dbd_postamble()".
374
375       The second hash reference in the call to "dbd_edit_mm_attribs()"
376       (containing "create_pp_tests()") is optional; you should not use it
377       unless your driver is a pure Perl driver (that is, it does not use C
378       and XS code). Therefore, the call to "dbd_edit_mm_attribs()" is not
379       relevant for C/XS drivers and may be omitted; simply use the (single)
380       hash reference containing NAME etc as the only argument to
381       "WriteMakefile()".
382
383       Note that the "dbd_edit_mm_attribs()" code will fail if you do not have
384       a t sub-directory containing at least one test case.
385
386       PREREQ_PM tells MakeMaker that DBI (version 1.03 in this case) is
387       required for this module. This will issue a warning that DBI 1.03 is
388       missing if someone attempts to install your DBD without DBI 1.03. See
389       CONFIGURE below for why this does not work reliably in stopping cpan
390       testers failing your module if DBI is not installed.
391
392       CONFIGURE is a subroutine called by MakeMaker during "WriteMakefile".
393       By putting the "require DBI::DBD" in this section we can attempt to
394       load DBI::DBD but if it is missing we exit with success. As we exit
395       successfully without creating a Makefile when DBI::DBD is missing cpan
396       testers will not report a failure. This may seem at odds with PREREQ_PM
397       but PREREQ_PM does not cause "WriteMakefile" to fail (unless you also
398       specify PREREQ_FATAL which is strongly discouraged by MakeMaker) so
399       "WriteMakefile" would continue to call "dbd_dbi_arch_dir" and fail.
400
401       All drivers must use "dbd_postamble()" or risk running into problems.
402
403       Note the specification of VERSION_FROM; the named file (Driver.pm) will
404       be scanned for the first line that looks like an assignment to
405       $VERSION, and the subsequent text will be used to determine the version
406       number.  Note the commentary in ExtUtils::MakeMaker on the subject of
407       correctly formatted version numbers.
408
409       If your driver depends upon external software (it usually will), you
410       will need to add code to ensure that your environment is workable
411       before the call to "WriteMakefile()". If you need to check for the
412       existence of an external library and perhaps modify INC to include the
413       paths to where the external library header files are located and you
414       cannot find the library or header files make sure you output a message
415       saying they cannot be found but "exit 0" (success) before calling
416       "WriteMakefile" or CPAN testers will fail your module if the external
417       library is not found.
418
419       A full-fledged Makefile.PL can be quite large (for example, the files
420       for DBD::Oracle and DBD::Informix are both over 1000 lines long, and
421       the Informix one uses - and creates - auxiliary modules too).
422
423       See also ExtUtils::MakeMaker and ExtUtils::MM_Unix. Consider using
424       CPAN::MakeMaker in place of ExtUtils::MakeMaker.
425
426   README
427       The README file should describe what the driver is for, the pre-
428       requisites for the build process, the actual build process, how to
429       report errors, and who to report them to.
430
431       Users will find ways of breaking the driver build and test process
432       which you would never even have dreamed to be possible in your worst
433       nightmares. Therefore, you need to write this document defensively,
434       precisely and concisely.
435
436       As always, use the README from one of the established drivers as a
437       basis for your own; the version in DBD::Informix is worth a look as it
438       has been quite successful in heading off problems.
439
440       ·   Note that users will have versions of Perl and DBI that are both
441           older and newer than you expected, but this will seldom cause much
442           trouble.  When it does, it will be because you are using features
443           of DBI that are not supported in the version they are using.
444
445       ·   Note that users will have versions of the database software that
446           are both older and newer than you expected. You will save yourself
447           time in the long run if you can identify the range of versions
448           which have been tested and warn about versions which are not known
449           to be OK.
450
451       ·   Note that many people trying to install your driver will not be
452           experts in the database software.
453
454       ·   Note that many people trying to install your driver will not be
455           experts in C or Perl.
456
457   MANIFEST
458       The MANIFEST will be used by the Makefile's dist target to build the
459       distribution tar file that is uploaded to CPAN. It should list every
460       file that you want to include in your distribution, one per line.
461
462   lib/Bundle/DBD/Driver.pm
463       The CPAN module provides an extremely powerful bundle mechanism that
464       allows you to specify pre-requisites for your driver.
465
466       The primary pre-requisite is Bundle::DBI; you may want or need to add
467       some more. With the bundle set up correctly, the user can type:
468
469               perl -MCPAN -e 'install Bundle::DBD::Driver'
470
471       and Perl will download, compile, test and install all the Perl modules
472       needed to build your driver.
473
474       The prerequisite modules are listed in the "CONTENTS" section, with the
475       official name of the module followed by a dash and an informal name or
476       description.
477
478       ·   Listing Bundle::DBI as the main pre-requisite simplifies life.
479
480       ·   Don't forget to list your driver.
481
482       ·   Note that unless the DBMS is itself a Perl module, you cannot list
483           it as a pre-requisite in this file.
484
485       ·   You should keep the version of the bundle the same as the version
486           of your driver.
487
488       ·   You should add configuration management, copyright, and licencing
489           information at the top.
490
491       A suitable skeleton for this file is shown below.
492
493         package Bundle::DBD::Driver;
494
495         $VERSION = '0.01';
496
497         1;
498
499         __END__
500
501         =head1 NAME
502
503         Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules
504
505         =head1 SYNOPSIS
506
507         C<perl -MCPAN -e 'install Bundle::DBD::Driver'>
508
509         =head1 CONTENTS
510
511         Bundle::DBI  - Bundle for DBI by TIMB (Tim Bunce)
512
513         DBD::Driver  - DBD::Driver by YOU (Your Name)
514
515         =head1 DESCRIPTION
516
517         This bundle includes all the modules used by the Perl Database
518         Interface (DBI) driver for Driver (DBD::Driver), assuming the
519         use of DBI version 1.13 or later, created by Tim Bunce.
520
521         If you've not previously used the CPAN module to install any
522         bundles, you will be interrogated during its setup phase.
523         But when you've done it once, it remembers what you told it.
524         You could start by running:
525
526           C<perl -MCPAN -e 'install Bundle::CPAN'>
527
528         =head1 SEE ALSO
529
530         Bundle::DBI
531
532         =head1 AUTHOR
533
534         Your Name E<lt>F<you@yourdomain.com>E<gt>
535
536         =head1 THANKS
537
538         This bundle was created by ripping off Bundle::libnet created by
539         Graham Barr E<lt>F<gbarr@ti.com>E<gt>, and radically simplified
540         with some information from Jochen Wiedmann E<lt>F<joe@ispsoft.de>E<gt>.
541         The template was then included in the DBI::DBD documentation by
542         Jonathan Leffler E<lt>F<jleffler@informix.com>E<gt>.
543
544         =cut
545
546   lib/DBD/Driver/Summary.pm
547       There is no substitute for taking the summary file from a driver that
548       was documented in the Perl book (such as DBD::Oracle or DBD::Informix
549       or DBD::ODBC, to name but three), and adapting it to describe the
550       facilities available via DBD::Driver when accessing the Driver
551       database.
552
553   Pure Perl version of Driver.pm
554       The Driver.pm file defines the Perl module DBD::Driver for your driver.
555       It will define a package DBD::Driver along with some version
556       information, some variable definitions, and a function "driver()" which
557       will have a more or less standard structure.
558
559       It will also define three sub-packages of DBD::Driver:
560
561       DBD::Driver::dr
562           with methods "connect()", "data_sources()" and "disconnect_all()";
563
564       DBD::Driver::db
565           with methods such as "prepare()";
566
567       DBD::Driver::st
568           with methods such as "execute()" and "fetch()".
569
570       The Driver.pm file will also contain the documentation specific to
571       DBD::Driver in the format used by perldoc.
572
573       In a pure Perl driver, the Driver.pm file is the core of the
574       implementation. You will need to provide all the key methods needed by
575       DBI.
576
577       Now let's take a closer look at an excerpt of File.pm as an example.
578       We ignore things that are common to any module (even non-DBI modules)
579       or really specific to the DBD::File package.
580
581       The DBD::Driver package
582
583       The header
584
585         package DBD::File;
586
587         use strict;
588         use vars qw($VERSION $drh);
589
590         $VERSION = "1.23.00"  # Version number of DBD::File
591
592       This is where the version number of your driver is specified, and is
593       where Makefile.PL looks for this information. Please ensure that any
594       other modules added with your driver are also version stamped so that
595       CPAN does not get confused.
596
597       It is recommended that you use a two-part (1.23) or three-part
598       (1.23.45) version number. Also consider the CPAN system, which gets
599       confused and considers version 1.10 to precede version 1.9, so that
600       using a raw CVS, RCS or SCCS version number is probably not appropriate
601       (despite being very common).
602
603       For Subversion you could use:
604
605         $VERSION = "12.012346";
606
607       (use lots of leading zeros on the second portion so if you move the
608       code to a shared repository like svn.perl.org the much larger revision
609       numbers won't cause a problem, at least not for a few years).  For RCS
610       or CVS you can use:
611
612         $VERSION = "11.22";
613
614       which pads out the fractional part with leading zeros so all is well
615       (so long as you don't go past x.99)
616
617         $drh = undef;         # holds driver handle once initialized
618
619       This is where the driver handle will be stored, once created.  Note
620       that you may assume there is only one handle for your driver.
621
622       The driver constructor
623
624       The "driver()" method is the driver handle constructor. Note that the
625       "driver()" method is in the DBD::Driver package, not in one of the sub-
626       packages DBD::Driver::dr, DBD::Driver::db, or DBD::Driver::db.
627
628         sub driver
629         {
630             return $drh if $drh;      # already created - return same one
631             my ($class, $attr) = @_;
632
633             $class .= "::dr";
634
635             DBD::Driver::db->install_method('drv_example_dbh_method');
636             DBD::Driver::st->install_method('drv_example_sth_method');
637
638             # not a 'my' since we use it above to prevent multiple drivers
639             $drh = DBI::_new_drh($class, {
640                     'Name'        => 'File',
641                     'Version'     => $VERSION,
642                     'Attribution' => 'DBD::File by Jochen Wiedmann',
643                 })
644                 or return undef;
645
646             return $drh;
647         }
648
649       This is a reasonable example of how DBI implements its handles. There
650       are three kinds: driver handles (typically stored in $drh; from now on
651       called drh or $drh), database handles (from now on called dbh or $dbh)
652       and statement handles (from now on called sth or $sth).
653
654       The prototype of "DBI::_new_drh()" is
655
656         $drh = DBI::_new_drh($class, $public_attrs, $private_attrs);
657
658       with the following arguments:
659
660       $class
661           is typically the class for your driver, (for example,
662           "DBD::File::dr"), passed as the first argument to the "driver()"
663           method.
664
665       $public_attrs
666           is a hash ref to attributes like Name, Version, and Attribution.
667           These are processed and used by DBI. You had better not make any
668           assumptions about them nor should you add private attributes here.
669
670       $private_attrs
671           This is another (optional) hash ref with your private attributes.
672           DBI will store them and otherwise leave them alone.
673
674       The "DBI::_new_drh()" method and the "driver()" method both return
675       "undef" for failure (in which case you must look at $DBI::err and
676       $DBI::errstr for the failure information, because you have no driver
677       handle to use).
678
679       Using install_method() to expose driver-private methods
680
681           DBD::Foo::db->install_method($method_name, \%attr);
682
683       Installs the driver-private method named by $method_name into the DBI
684       method dispatcher so it can be called directly, avoiding the need to
685       use the func() method.
686
687       It is called as a static method on the driver class to which the method
688       belongs. The method name must begin with the corresponding registered
689       driver-private prefix. For example, for DBD::Oracle $method_name must
690       being with '"ora_"', and for DBD::AnyData it must begin with '"ad_"'.
691
692       The "\%attr" attributes can be used to provide fine control over how
693       the DBI dispatcher handles the dispatching of the method. However it's
694       undocumented at the moment. See the IMA_* #define's in DBI.xs and the
695       O=>0x000x values in the initialization of %DBI::DBI_methods in DBI.pm.
696       (Volunteers to polish up and document the interface are very welcome to
697       get in touch via dbi-dev@perl.org).
698
699       Methods installed using install_method default to the standard error
700       handling behaviour for DBI methods: clearing err and errstr before
701       calling the method, and checking for errors to trigger RaiseError etc.
702       on return. This differs from the default behaviour of func().
703
704       Note for driver authors: The DBD::Foo::xx->install_method call won't
705       work until the class-hierarchy has been setup. Normally the DBI looks
706       after that just after the driver is loaded. This means install_method()
707       can't be called at the time the driver is loaded unless the class-
708       hierarchy is set up first. The way to do that is to call the
709       setup_driver() method:
710
711           DBI->setup_driver('DBD::Foo');
712
713       before using install_method().
714
715       The CLONE special subroutine
716
717       Also needed here, in the DBD::Driver package, is a "CLONE()" method
718       that will be called by perl when an interpreter is cloned. All your
719       "CLONE()" method needs to do, currently, is clear the cached $drh so
720       the new interpreter won't start using the cached $drh from the old
721       interpreter:
722
723         sub CLONE {
724           undef $drh;
725         }
726
727       See
728       <http://search.cpan.org/dist/perl/pod/perlmod.pod#Making_your_module_threadsafe>
729       for details.
730
731       The DBD::Driver::dr package
732
733       The next lines of code look as follows:
734
735         package DBD::Driver::dr; # ====== DRIVER ======
736
737         $DBD::Driver::dr::imp_data_size = 0;
738
739       Note that no @ISA is needed here, or for the other DBD::Driver::*
740       classes, because the DBI takes care of that for you when the driver is
741       loaded.
742
743        *FIX ME* Explain what the imp_data_size is, so that implementors aren't
744        practicing cargo-cult programming.
745
746       The database handle constructor
747
748       The database handle constructor is the driver's (hence the changed
749       namespace) "connect()" method:
750
751         sub connect
752         {
753             my ($drh, $dr_dsn, $user, $auth, $attr) = @_;
754
755             # Some database specific verifications, default settings
756             # and the like can go here. This should only include
757             # syntax checks or similar stuff where it's legal to
758             # 'die' in case of errors.
759             # For example, many database packages requires specific
760             # environment variables to be set; this could be where you
761             # validate that they are set, or default them if they are not set.
762
763             my $driver_prefix = "drv_"; # the assigned prefix for this driver
764
765             # Process attributes from the DSN; we assume ODBC syntax
766             # here, that is, the DSN looks like var1=val1;...;varN=valN
767             foreach my $var ( split /;/, $dr_dsn ) {
768                 my ($attr_name, $attr_value) = split '=', $var, 2;
769                 return $drh->set_err($DBI::stderr, "Can't parse DSN part '$var'")
770                     unless defined $attr_value;
771
772                 # add driver prefix to attribute name if it doesn't have it already
773                 $attr_name = $driver_prefix.$attr_name
774                     unless $attr_name =~ /^$driver_prefix/o;
775
776                 # Store attribute into %$attr, replacing any existing value.
777                 # The DBI will STORE() these into $dbh after we've connected
778                 $attr->{$attr_name} = $attr_value;
779             }
780
781             # Get the attributes we'll use to connect.
782             # We use delete here because these no need to STORE them
783             my $db = delete $attr->{drv_database} || delete $attr->{drv_db}
784                 or return $drh->set_err($DBI::stderr, "No database name given in DSN '$dr_dsn'");
785             my $host = delete $attr->{drv_host} || 'localhost';
786             my $port = delete $attr->{drv_port} || 123456;
787
788             # Assume you can attach to your database via drv_connect:
789             my $connection = drv_connect($db, $host, $port, $user, $auth)
790                 or return $drh->set_err($DBI::stderr, "Can't connect to $dr_dsn: ...");
791
792             # create a 'blank' dbh (call superclass constructor)
793             my ($outer, $dbh) = DBI::_new_dbh($drh, { Name => $dr_dsn });
794
795             $dbh->STORE('Active', 1 );
796             $dbh->{drv_connection} = $connection;
797
798             return $outer;
799         }
800
801       This is mostly the same as in the driver handle constructor above.  The
802       arguments are described in DBI.
803
804       The constructor "DBI::_new_dbh()" is called, returning a database
805       handle.  The constructor's prototype is:
806
807         ($outer, $inner) = DBI::_new_dbh($drh, $public_attr, $private_attr);
808
809       with similar arguments to those in the driver handle constructor,
810       except that the $class is replaced by $drh. The Name attribute is a
811       standard DBI attribute (see "Database Handle Attributes" in DBI).
812
813       In scalar context, only the outer handle is returned.
814
815       Note the use of the "STORE()" method for setting the dbh attributes.
816       That's because within the driver code, the handle object you have is
817       the 'inner' handle of a tied hash, not the outer handle that the users
818       of your driver have.
819
820       Because you have the inner handle, tie magic doesn't get invoked when
821       you get or set values in the hash. This is often very handy for speed
822       when you want to get or set simple non-special driver-specific
823       attributes.
824
825       However, some attribute values, such as those handled by the DBI like
826       PrintError, don't actually exist in the hash and must be read via
827       "$h->FETCH($attrib)" and set via "$h->STORE($attrib, $value)".  If in
828       any doubt, use these methods.
829
830       The data_sources() method
831
832       The "data_sources()" method must populate and return a list of valid
833       data sources, prefixed with the "dbi:Driver" incantation that allows
834       them to be used in the first argument of the "DBI->connect()" method.
835       An example of this might be scanning the $HOME/.odbcini file on Unix
836       for ODBC data sources (DSNs).
837
838       As a trivial example, consider a fixed list of data sources:
839
840         sub data_sources
841         {
842             my($drh, $attr) = @_;
843             my(@list) = ();
844             # You need more sophisticated code than this to set @list...
845             push @list, "dbi:Driver:abc";
846             push @list, "dbi:Driver:def";
847             push @list, "dbi:Driver:ghi";
848             # End of code to set @list
849             return @list;
850         }
851
852       The disconnect_all() method
853
854       If you need to release any resources when the driver is unloaded, you
855       can provide a disconnect_all method.
856
857       Other driver handle methods
858
859       If you need any other driver handle methods, they can follow here.
860
861       Error handling
862
863       It is quite likely that something fails in the connect method.  With
864       DBD::File for example, you might catch an error when setting the
865       current directory to something not existent by using the (driver-
866       specific) f_dir attribute.
867
868       To report an error, you use the "set_err()" method:
869
870         $h->set_err($err, $errmsg, $state);
871
872       This will ensure that the error is recorded correctly and that
873       RaiseError and PrintError etc are handled correctly.
874
875       Typically you'll always use the method instance, aka your method's
876       first argument.
877
878       As "set_err()" always returns "undef" your error handling code can
879       usually be simplified to something like this:
880
881         return $h->set_err($err, $errmsg, $state) if ...;
882
883       The DBD::Driver::db package
884
885         package DBD::Driver::db; # ====== DATABASE ======
886
887         $DBD::Driver::db::imp_data_size = 0;
888
889       The statement handle constructor
890
891       There's nothing much new in the statement handle constructor, which is
892       the "prepare()" method:
893
894         sub prepare
895         {
896             my ($dbh, $statement, @attribs) = @_;
897
898             # create a 'blank' sth
899             my ($outer, $sth) = DBI::_new_sth($dbh, { Statement => $statement });
900
901             $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//));
902
903             $sth->{drv_params} = [];
904
905             return $outer;
906         }
907
908       This is still the same -- check the arguments and call the super class
909       constructor "DBI::_new_sth()". Again, in scalar context, only the outer
910       handle is returned. The Statement attribute should be cached as shown.
911
912       Note the prefix drv_ in the attribute names: it is required that all
913       your private attributes use a lowercase prefix unique to your driver.
914       As mentioned earlier in this document, the DBI contains a registry of
915       known driver prefixes and may one day warn about unknown attributes
916       that don't have a registered prefix.
917
918       Note that we parse the statement here in order to set the attribute
919       NUM_OF_PARAMS. The technique illustrated is not very reliable; it can
920       be confused by question marks appearing in quoted strings, delimited
921       identifiers or in SQL comments that are part of the SQL statement. We
922       could set NUM_OF_PARAMS in the "execute()" method instead because the
923       DBI specification explicitly allows a driver to defer this, but then
924       the user could not call "bind_param()".
925
926       Transaction handling
927
928       Pure Perl drivers will rarely support transactions. Thus your
929       "commit()" and "rollback()" methods will typically be quite simple:
930
931         sub commit
932         {
933             my ($dbh) = @_;
934             if ($dbh->FETCH('Warn')) {
935                 warn("Commit ineffective while AutoCommit is on");
936             }
937             0;
938         }
939
940         sub rollback {
941             my ($dbh) = @_;
942             if ($dbh->FETCH('Warn')) {
943                 warn("Rollback ineffective while AutoCommit is on");
944             }
945             0;
946         }
947
948       Or even simpler, just use the default methods provided by the DBI that
949       do nothing except return "undef".
950
951       The DBI's default "begin_work()" method can be used by inheritance.
952
953       The STORE() and FETCH() methods
954
955       These methods (that we have already used, see above) are called for
956       you, whenever the user does a:
957
958         $dbh->{$attr} = $val;
959
960       or, respectively,
961
962         $val = $dbh->{$attr};
963
964       See perltie for details on tied hash refs to understand why these
965       methods are required.
966
967       The DBI will handle most attributes for you, in particular attributes
968       like RaiseError or PrintError. All you have to do is handle your
969       driver's private attributes and any attributes, like AutoCommit and
970       ChopBlanks, that the DBI can't handle for you.
971
972       A good example might look like this:
973
974         sub STORE
975         {
976             my ($dbh, $attr, $val) = @_;
977             if ($attr eq 'AutoCommit') {
978                 # AutoCommit is currently the only standard attribute we have
979                 # to consider.
980                 if (!$val) { die "Can't disable AutoCommit"; }
981                 return 1;
982             }
983             if ($attr =~ m/^drv_/) {
984                 # Handle only our private attributes here
985                 # Note that we could trigger arbitrary actions.
986                 # Ideally we should warn about unknown attributes.
987                 $dbh->{$attr} = $val; # Yes, we are allowed to do this,
988                 return 1;             # but only for our private attributes
989             }
990             # Else pass up to DBI to handle for us
991             $dbh->SUPER::STORE($attr, $val);
992         }
993
994         sub FETCH
995         {
996             my ($dbh, $attr) = @_;
997             if ($attr eq 'AutoCommit') { return 1; }
998             if ($attr =~ m/^drv_/) {
999                 # Handle only our private attributes here
1000                 # Note that we could trigger arbitrary actions.
1001                 return $dbh->{$attr}; # Yes, we are allowed to do this,
1002                                       # but only for our private attributes
1003             }
1004             # Else pass up to DBI to handle
1005             $dbh->SUPER::FETCH($attr);
1006         }
1007
1008       The DBI will actually store and fetch driver-specific attributes (with
1009       all lowercase names) without warning or error, so there's actually no
1010       need to implement driver-specific any code in your "FETCH()" and
1011       "STORE()" methods unless you need extra logic/checks, beyond getting or
1012       setting the value.
1013
1014       Unless your driver documentation indicates otherwise, the return value
1015       of the "STORE()" method is unspecified and the caller shouldn't use
1016       that value.
1017
1018       Other database handle methods
1019
1020       As with the driver package, other database handle methods may follow
1021       here.  In particular you should consider a (possibly empty)
1022       "disconnect()" method and possibly a "quote()" method if DBI's default
1023       isn't correct for you. You may also need the "type_info_all()" and
1024       "get_info()" methods, as described elsewhere in this document.
1025
1026       Where reasonable use "$h->SUPER::foo()" to call the DBI's method in
1027       some or all cases and just wrap your custom behavior around that.
1028
1029       If you want to use private trace flags you'll probably want to be able
1030       to set them by name. To do that you'll need to define a
1031       "parse_trace_flag()" method (note that's "parse_trace_flag", singular,
1032       not "parse_trace_flags", plural).
1033
1034         sub parse_trace_flag {
1035             my ($h, $name) = @_;
1036             return 0x01000000 if $name eq 'foo';
1037             return 0x02000000 if $name eq 'bar';
1038             return 0x04000000 if $name eq 'baz';
1039             return 0x08000000 if $name eq 'boo';
1040             return 0x10000000 if $name eq 'bop';
1041             return $h->SUPER::parse_trace_flag($name);
1042         }
1043
1044       All private flag names must be lowercase, and all private flags must be
1045       in the top 8 of the 32 bits.
1046
1047       The DBD::Driver::st package
1048
1049       This package follows the same pattern the others do:
1050
1051         package DBD::Driver::st;
1052
1053         $DBD::Driver::st::imp_data_size = 0;
1054
1055       The execute() and bind_param() methods
1056
1057       This is perhaps the most difficult method because we have to consider
1058       parameter bindings here. In addition to that, there are a number of
1059       statement attributes which must be set for inherited DBI methods to
1060       function correctly (see "Statement attributes" below).
1061
1062       We present a simplified implementation by using the drv_params
1063       attribute from above:
1064
1065         sub bind_param
1066         {
1067             my ($sth, $pNum, $val, $attr) = @_;
1068             my $type = (ref $attr) ? $attr->{TYPE} : $attr;
1069             if ($type) {
1070                 my $dbh = $sth->{Database};
1071                 $val = $dbh->quote($sth, $type);
1072             }
1073             my $params = $sth->{drv_params};
1074             $params->[$pNum-1] = $val;
1075             1;
1076         }
1077
1078         sub execute
1079         {
1080             my ($sth, @bind_values) = @_;
1081
1082             # start of by finishing any previous execution if still active
1083             $sth->finish if $sth->FETCH('Active');
1084
1085             my $params = (@bind_values) ?
1086                 \@bind_values : $sth->{drv_params};
1087             my $numParam = $sth->FETCH('NUM_OF_PARAMS');
1088             return $sth->set_err($DBI::stderr, "Wrong number of parameters")
1089                 if @$params != $numParam;
1090             my $statement = $sth->{'Statement'};
1091             for (my $i = 0;  $i < $numParam;  $i++) {
1092                 $statement =~ s/?/$params->[$i]/; # XXX doesn't deal with quoting etc!
1093             }
1094             # Do anything ... we assume that an array ref of rows is
1095             # created and store it:
1096             $sth->{'drv_data'} = $data;
1097             $sth->{'drv_rows'} = @$data; # number of rows
1098             $sth->STORE('NUM_OF_FIELDS') = $numFields;
1099             $sth->{Active} = 1;
1100             @$data || '0E0';
1101         }
1102
1103       There are a number of things you should note here.
1104
1105       We initialize the NUM_OF_FIELDS and Active attributes here, because
1106       they are essential for "bind_columns()" to work.
1107
1108       We use attribute "$sth->{Statement}" which we created within
1109       "prepare()". The attribute "$sth->{Database}", which is nothing else
1110       than the dbh, was automatically created by DBI.
1111
1112       Finally, note that (as specified in the DBI specification) we return
1113       the string '0E0' instead of the number 0, so that the result tests true
1114       but equal to zero.
1115
1116         $sth->execute() or die $sth->errstr;
1117
1118       The execute_array(), execute_for_fetch() and bind_param_array() methods
1119
1120       In general, DBD's only need to implement "execute_for_fetch()" and
1121       "bind_param_array". DBI's default "execute_array()" will invoke the
1122       DBD's "execute_for_fetch()" as needed.
1123
1124       The following sequence describes the interaction between DBI
1125       "execute_array" and a DBD's "execute_for_fetch":
1126
1127       1.  App calls "$sth->execute_array(\%attrs, @array_of_arrays)"
1128
1129       2.  If @array_of_arrays was specified, DBI processes @array_of_arrays
1130           by calling DBD's "bind_param_array()". Alternately, App may have
1131           directly called "bind_param_array()"
1132
1133       3.  DBD validates and binds each array
1134
1135       4.  DBI retrieves the validated param arrays from DBD's ParamArray
1136           attribute
1137
1138       5.  DBI calls DBD's "execute_for_fetch($fetch_tuple_sub,
1139           \@tuple_status)", where &$fetch_tuple_sub is a closure to iterate
1140           over the returned ParamArray values, and "\@tuple_status" is an
1141           array to receive the disposition status of each tuple.
1142
1143       6.  DBD iteratively calls &$fetch_tuple_sub to retrieve parameter
1144           tuples to be added to its bulk database operation/request.
1145
1146       7.  when DBD reaches the limit of tuples it can handle in a single
1147           database operation/request, or the &$fetch_tuple_sub indicates no
1148           more tuples by returning undef, the DBD executes the bulk
1149           operation, and reports the disposition of each tuple in
1150           \@tuple_status.
1151
1152       8.  DBD repeats steps 6 and 7 until all tuples are processed.
1153
1154       E.g., here's the essence of DBD::Oracle's execute_for_fetch:
1155
1156              while (1) {
1157                  my @tuple_batch;
1158                  for (my $i = 0; $i < $batch_size; $i++) {
1159                       push @tuple_batch, [ @{$fetch_tuple_sub->() || last} ];
1160                  }
1161                  last unless @tuple_batch;
1162                  my $res = ora_execute_array($sth, \@tuple_batch,
1163                     scalar(@tuple_batch), $tuple_batch_status);
1164                  push @$tuple_status, @$tuple_batch_status;
1165              }
1166
1167       Note that DBI's default execute_array()/execute_for_fetch()
1168       implementation requires the use of positional (i.e., '?') placeholders.
1169       Drivers which require named placeholders must either emulate positional
1170       placeholders (e.g., see DBD::Oracle), or must implement their own
1171       execute_array()/execute_for_fetch() methods to properly sequence bound
1172       parameter arrays.
1173
1174       Fetching data
1175
1176       Only one method needs to be written for fetching data,
1177       "fetchrow_arrayref()".  The other methods, "fetchrow_array()",
1178       "fetchall_arrayref()", etc, as well as the database handle's "select*"
1179       methods are part of DBI, and call "fetchrow_arrayref()" as necessary.
1180
1181         sub fetchrow_arrayref
1182         {
1183             my ($sth) = @_;
1184             my $data = $sth->{drv_data};
1185             my $row = shift @$data;
1186             if (!$row) {
1187                 $sth->STORE(Active => 0); # mark as no longer active
1188                 return undef;
1189             }
1190             if ($sth->FETCH('ChopBlanks')) {
1191                 map { $_ =~ s/\s+$//; } @$row;
1192             }
1193             return $sth->_set_fbav($row);
1194         }
1195         *fetch = \&fetchrow_arrayref; # required alias for fetchrow_arrayref
1196
1197       Note the use of the method "_set_fbav()" -- this is required so that
1198       "bind_col()" and "bind_columns()" work.
1199
1200       If an error occurs which leaves the $sth in a state where remaining
1201       rows can't be fetched then Active should be turned off before the
1202       method returns.
1203
1204       The "rows()" method for this driver can be implemented like this:
1205
1206         sub rows { shift->{drv_rows} }
1207
1208       because it knows in advance how many rows it has fetched.
1209       Alternatively you could delete that method and so fallback to the DBI's
1210       own method which does the right thing based on the number of calls to
1211       "_set_fbav()".
1212
1213       The more_results method
1214
1215       If your driver doesn't support multiple result sets, then don't even
1216       implement this method.
1217
1218       Otherwise, this method needs to get the statement handle ready to fetch
1219       results from the next result set, if there is one. Typically you'd
1220       start with:
1221
1222           $sth->finish;
1223
1224       then you should delete all the attributes from the attribute cache that
1225       may no longer be relevant for the new result set:
1226
1227           delete $sth->{$_}
1228               for qw(NAME TYPE PRECISION SCALE ...);
1229
1230       for drivers written in C use:
1231
1232           hv_delete((HV*)SvRV(sth), "NAME", 4, G_DISCARD);
1233           hv_delete((HV*)SvRV(sth), "NULLABLE", 8, G_DISCARD);
1234           hv_delete((HV*)SvRV(sth), "NUM_OF_FIELDS", 13, G_DISCARD);
1235           hv_delete((HV*)SvRV(sth), "PRECISION", 9, G_DISCARD);
1236           hv_delete((HV*)SvRV(sth), "SCALE", 5, G_DISCARD);
1237           hv_delete((HV*)SvRV(sth), "TYPE", 4, G_DISCARD);
1238
1239       Don't forget to also delete, or update, any driver-private attributes
1240       that may not be correct for the next resultset.
1241
1242       The NUM_OF_FIELDS attribute is a special case. It should be set using
1243       STORE:
1244
1245           $sth->STORE(NUM_OF_FIELDS => 0); /* for DBI <= 1.53 */
1246           $sth->STORE(NUM_OF_FIELDS => $new_value);
1247
1248       for drivers written in C use this incantation:
1249
1250           /* Adjust NUM_OF_FIELDS - which also adjusts the row buffer size */
1251           DBIc_NUM_FIELDS(imp_sth) = 0; /* for DBI <= 1.53 */
1252           DBIc_STATE(imp_xxh)->set_attr_k(sth, sv_2mortal(newSVpvn("NUM_OF_FIELDS",13)), 0,
1253               sv_2mortal(newSViv(mysql_num_fields(imp_sth->result)))
1254           );
1255
1256       For DBI versions prior to 1.54 you'll also need to explicitly adjust
1257       the number of elements in the row buffer array
1258       ("DBIc_FIELDS_AV(imp_sth)") to match the new result set. Fill any new
1259       values with newSV(0) not &sv_undef.  Alternatively you could free
1260       DBIc_FIELDS_AV(imp_sth) and set it to null, but that would mean
1261       bind_columns() wouldn't work across result sets.
1262
1263       Statement attributes
1264
1265       The main difference between dbh and sth attributes is, that you should
1266       implement a lot of attributes here that are required by the DBI, such
1267       as NAME, NULLABLE, TYPE, etc. See "Statement Handle Attributes" in DBI
1268       for a complete list.
1269
1270       Pay attention to attributes which are marked as read only, such as
1271       NUM_OF_PARAMS. These attributes can only be set the first time a
1272       statement is executed. If a statement is prepared, then executed
1273       multiple times, warnings may be generated.
1274
1275       You can protect against these warnings, and prevent the recalculation
1276       of attributes which might be expensive to calculate (such as the NAME
1277       and NAME_* attributes):
1278
1279           my $storedNumParams = $sth->FETCH('NUM_OF_PARAMS');
1280           if (!defined $storedNumParams or $storedNumFields < 0) {
1281               $sth->STORE('NUM_OF_PARAMS') = $numParams;
1282
1283               # Set other useful attributes that only need to be set once
1284               # for a statement, like $sth->{NAME} and $sth->{TYPE}
1285           }
1286
1287       One particularly important attribute to set correctly (mentioned in
1288       "ATTRIBUTES COMMON TO ALL HANDLES" in DBI is Active. Many DBI methods,
1289       including "bind_columns()", depend on this attribute.
1290
1291       Besides that the "STORE()" and "FETCH()" methods are mainly the same as
1292       above for dbh's.
1293
1294       Other statement methods
1295
1296       A trivial "finish()" method to discard stored data, reset any
1297       attributes (such as Active) and do "$sth->SUPER::finish()".
1298
1299       If you've defined a "parse_trace_flag()" method in ::db you'll also
1300       want it in ::st, so just alias it in:
1301
1302         *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;
1303
1304       And perhaps some other methods that are not part of the DBI
1305       specification, in particular to make metadata available.  Remember that
1306       they must have names that begin with your drivers registered prefix so
1307       they can be installed using "install_method()".
1308
1309       If "DESTROY()" is called on a statement handle that's still active
1310       ("$sth->{Active}" is true) then it should effectively call "finish()".
1311
1312           sub DESTROY {
1313               my $sth = shift;
1314               $sth->finish if $sth->FETCH('Active');
1315           }
1316
1317   Tests
1318       The test process should conform as closely as possibly to the Perl
1319       standard test harness.
1320
1321       In particular, most (all) of the tests should be run in the t sub-
1322       directory, and should simply produce an "ok" when run under "make
1323       test".  For details on how this is done, see the Camel book and the
1324       section in Chapter 7, "The Standard Perl Library" on Test::Harness.
1325
1326       The tests may need to adapt to the type of database which is being used
1327       for testing, and to the privileges of the user testing the driver. For
1328       example, the DBD::Informix test code has to adapt in a number of places
1329       to the type of database to which it is connected as different Informix
1330       databases have different capabilities: some of the tests are for
1331       databases without transaction logs; others are for databases with a
1332       transaction log; some versions of the server have support for blobs, or
1333       stored procedures, or user-defined data types, and others do not.
1334
1335       When a complete file of tests must be skipped, you can provide a reason
1336       in a pseudo-comment:
1337
1338           if ($no_transactions_available)
1339           {
1340               print "1..0 # Skip: No transactions available\n";
1341               exit 0;
1342           }
1343
1344       Consider downloading the DBD::Informix code and look at the code in
1345       DBD/Informix/TestHarness.pm which is used throughout the DBD::Informix
1346       tests in the t sub-directory.
1347

CREATING A C/XS DRIVER

1349       Please also see the section under "CREATING A PURE PERL DRIVER"
1350       regarding the creation of the Makefile.PL.
1351
1352       Creating a new C/XS driver from scratch will always be a daunting task.
1353       You can and should greatly simplify your task by taking a good
1354       reference driver implementation and modifying that to match the
1355       database product for which you are writing a driver.
1356
1357       The de facto reference driver has been the one for DBD::Oracle written
1358       by Tim Bunce, who is also the author of the DBI package. The
1359       DBD::Oracle module is a good example of a driver implemented around a
1360       C-level API.
1361
1362       Nowadays it it seems better to base on DBD::ODBC, another driver
1363       maintained by Tim and Jeff Urlwin, because it offers a lot of metadata
1364       and seems to become the guideline for the future development. (Also as
1365       DBD::Oracle digs deeper into the Oracle 8 OCI interface it'll get even
1366       more hairy than it is now.)
1367
1368       The DBD::Informix driver is one driver implemented using embedded SQL
1369       instead of a function-based API.  DBD::Ingres may also be worth a look.
1370
1371   C/XS version of Driver.pm
1372       A lot of the code in the Driver.pm file is very similar to the code for
1373       pure Perl modules - see above.  However, there are also some subtle
1374       (and not so subtle) differences, including:
1375
1376       ·       The variables $DBD::Driver::{dr|db|st}::imp_data_size are not
1377               defined here, but in the XS code, because they declare the size
1378               of certain C structures.
1379
1380       ·       Some methods are typically moved to the XS code, in particular
1381               "prepare()", "execute()", "disconnect()", "disconnect_all()"
1382               and the "STORE()" and "FETCH()" methods.
1383
1384       ·       Other methods are still part of Driver.pm, but have callbacks
1385               to the XS code.
1386
1387       ·       If the driver-specific parts of the imp_drh_t structure need to
1388               be formally initialized (which does not seem to be a common
1389               requirement), then you need to add a call to an appropriate XS
1390               function in the driver method of "DBD::Driver::driver()", and
1391               you define the corresponding function in Driver.xs, and you
1392               define the C code in dbdimp.c and the prototype in dbdimp.h.
1393
1394               For example, DBD::Informix has such a requirement, and adds the
1395               following call after the call to "_new_drh()" in Informix.pm:
1396
1397                 DBD::Informix::dr::driver_init($drh);
1398
1399               and the following code in Informix.xs:
1400
1401                 # Initialize the DBD::Informix driver data structure
1402                 void
1403                 driver_init(drh)
1404                     SV *drh
1405                     CODE:
1406                     ST(0) = dbd_ix_dr_driver_init(drh) ? &sv_yes : &sv_no;
1407
1408               and the code in dbdimp.h declares:
1409
1410                 extern int dbd_ix_dr_driver_init(SV *drh);
1411
1412               and the code in dbdimp.ec (equivalent to dbdimp.c) defines:
1413
1414                 /* Formally initialize the DBD::Informix driver structure */
1415                 int
1416                 dbd_ix_dr_driver(SV *drh)
1417                 {
1418                     D_imp_drh(drh);
1419                     imp_drh->n_connections = 0;       /* No active connections */
1420                     imp_drh->current_connection = 0;  /* No current connection */
1421                     imp_drh->multipleconnections = (ESQLC_VERSION >= 600) ? True : False;
1422                     dbd_ix_link_newhead(&imp_drh->head);  /* Empty linked list of connections */
1423                     return 1;
1424                 }
1425
1426               DBD::Oracle has a similar requirement but gets around it by
1427               checking whether the private data part of the driver handle is
1428               all zeroed out, rather than add extra functions.
1429
1430       Now let's take a closer look at an excerpt from Oracle.pm (revised
1431       heavily to remove idiosyncrasies) as an example, ignoring things that
1432       were already discussed for pure Perl drivers.
1433
1434       The connect method
1435
1436       The connect method is the database handle constructor.  You could write
1437       either of two versions of this method: either one which takes
1438       connection attributes (new code) and one which ignores them (old code
1439       only).
1440
1441       If you ignore the connection attributes, then you omit all mention of
1442       the $auth variable (which is a reference to a hash of attributes), and
1443       the XS system manages the differences for you.
1444
1445         sub connect
1446         {
1447             my ($drh, $dbname, $user, $auth, $attr) = @_;
1448
1449             # Some database specific verifications, default settings
1450             # and the like following here. This should only include
1451             # syntax checks or similar stuff where it's legal to
1452             # 'die' in case of errors.
1453
1454             my $dbh = DBI::_new_dbh($drh, {
1455                     'Name'   => $dbname,
1456                 })
1457                 or return undef;
1458
1459             # Call the driver-specific function _login in Driver.xs file which
1460             # calls the DBMS-specific function(s) to connect to the database,
1461             # and populate internal handle data.
1462             DBD::Driver::db::_login($dbh, $dbname, $user, $auth, $attr)
1463                 or return undef;
1464
1465             $dbh;
1466         }
1467
1468       This is mostly the same as in the pure Perl case, the exception being
1469       the use of the private "_login()" callback, which is the function that
1470       will really connect to the database. It is implemented in Driver.xst
1471       (you should not implement it) and calls "dbd_db_login6()" or
1472       "dbd_db_login6_sv" from dbdimp.c. See below for details.
1473
1474       If your driver has driver-specific attributes which may be passed in
1475       the connect method and hence end up in $attr in "dbd_db_login6" then it
1476       is best to delete any you process so DBI does not send them again via
1477       STORE after connect. You can do this in C like this:
1478
1479         DBD_ATTRIB_DELETE(attr, "my_attribute_name",
1480                           strlen("my_attribute_name"));
1481
1482       However, prior to DBI subversion version 11605 (and fixed post 1.607)
1483       DBD_ATTRIB_DELETE segfaulted so if you cannot guarantee the DBI version
1484       will be post 1.607 you need to use:
1485
1486         hv_delete((HV*)SvRV(attr), "my_attribute_name",
1487                            strlen("my_attribute_name"), G_DISCARD);
1488
1489        *FIX ME* Discuss removing attributes in Perl code.
1490
1491       The disconnect_all method
1492
1493        *FIX ME* T.B.S
1494
1495       The data_sources method
1496
1497       If your "data_sources()" method can be implemented in pure Perl, then
1498       do so because it is easier than doing it in XS code (see the section
1499       above for pure Perl drivers).
1500
1501       If your "data_sources()" method must call onto compiled functions, then
1502       you will need to define dbd_dr_data_sources in your dbdimp.h file,
1503       which will trigger Driver.xst (in DBI v1.33 or greater) to generate the
1504       XS code that calls your actual C function (see the discussion below for
1505       details) and you do not code anything in Driver.pm to handle it.
1506
1507       The prepare method
1508
1509       The prepare method is the statement handle constructor, and most of it
1510       is not new. Like the "connect()" method, it now has a C callback:
1511
1512         package DBD::Driver::db; # ====== DATABASE ======
1513         use strict;
1514
1515         sub prepare
1516         {
1517             my ($dbh, $statement, $attribs) = @_;
1518
1519             # create a 'blank' sth
1520             my $sth = DBI::_new_sth($dbh, {
1521                 'Statement' => $statement,
1522                 })
1523                 or return undef;
1524
1525             # Call the driver-specific function _prepare in Driver.xs file
1526             # which calls the DBMS-specific function(s) to prepare a statement
1527             # and populate internal handle data.
1528             DBD::Driver::st::_prepare($sth, $statement, $attribs)
1529                 or return undef;
1530             $sth;
1531         }
1532
1533       The execute method
1534
1535        *FIX ME* T.B.S
1536
1537       The fetchrow_arrayref method
1538
1539        *FIX ME* T.B.S
1540
1541       Other methods?
1542
1543        *FIX ME* T.B.S
1544
1545   Driver.xs
1546       Driver.xs should look something like this:
1547
1548         #include "Driver.h"
1549
1550         DBISTATE_DECLARE;
1551
1552         INCLUDE: Driver.xsi
1553
1554         MODULE = DBD::Driver    PACKAGE = DBD::Driver::dr
1555
1556         /* Non-standard drh XS methods following here, if any.       */
1557         /* If none (the usual case), omit the MODULE line above too. */
1558
1559         MODULE = DBD::Driver    PACKAGE = DBD::Driver::db
1560
1561         /* Non-standard dbh XS methods following here, if any.       */
1562         /* Currently this includes things like _list_tables from     */
1563         /* DBD::mSQL and DBD::mysql.                                 */
1564
1565         MODULE = DBD::Driver    PACKAGE = DBD::Driver::st
1566
1567         /* Non-standard sth XS methods following here, if any.       */
1568         /* In particular this includes things like _list_fields from */
1569         /* DBD::mSQL and DBD::mysql for accessing metadata.          */
1570
1571       Note especially the include of Driver.xsi here: DBI inserts stub
1572       functions for almost all private methods here which will typically do
1573       much work for you.
1574
1575       Wherever you really have to implement something, it will call a private
1576       function in dbdimp.c, and this is what you have to implement.
1577
1578       You need to set up an extra routine if your driver needs to export
1579       constants of its own, analogous to the SQL types available when you
1580       say:
1581
1582         use DBI qw(:sql_types);
1583
1584        *FIX ME* T.B.S
1585
1586   Driver.h
1587       Driver.h is very simple and the operational contents should look like
1588       this:
1589
1590         #ifndef DRIVER_H_INCLUDED
1591         #define DRIVER_H_INCLUDED
1592
1593         #define NEED_DBIXS_VERSION 93    /* 93 for DBI versions 1.00 to 1.51+ */
1594         #define PERL_NO_GET_CONTEXT      /* if used require DBI 1.51+ */
1595
1596         #include <DBIXS.h>      /* installed by the DBI module  */
1597
1598         #include "dbdimp.h"
1599
1600         #include "dbivport.h"   /* see below                    */
1601
1602         #include <dbd_xsh.h>    /* installed by the DBI module  */
1603
1604         #endif /* DRIVER_H_INCLUDED */
1605
1606       The DBIXS.h header defines most of the interesting information that the
1607       writer of a driver needs.
1608
1609       The file dbd_xsh.h header provides prototype declarations for the C
1610       functions that you might decide to implement. Note that you should
1611       normally only define one of "dbd_db_login()", "dbd_db_login6()" or
1612       "dbd_db_login6_sv" unless you are intent on supporting really old
1613       versions of DBI (prior to DBI 1.06) as well as modern versions. The
1614       only standard, DBI-mandated functions that you need write are those
1615       specified in the dbd_xsh.h header. You might also add extra driver-
1616       specific functions in Driver.xs.
1617
1618       The dbivport.h file should be copied from the latest DBI release into
1619       your distribution each time you modify your driver. Its job is to allow
1620       you to enhance your code to work with the latest DBI API while still
1621       allowing your driver to be compiled and used with older versions of the
1622       DBI (for example, when the "DBIh_SET_ERR_CHAR()" macro was added to DBI
1623       1.41, an emulation of it was added to dbivport.h). This makes users
1624       happy and your life easier. Always read the notes in dbivport.h to
1625       check for any limitations in the emulation that you should be aware of.
1626
1627       With DBI v1.51 or better I recommend that the driver defines
1628       PERL_NO_GET_CONTEXT before DBIXS.h is included. This can significantly
1629       improve efficiency when running under a thread enabled perl. (Remember
1630       that the standard perl in most Linux distributions is built with
1631       threads enabled.  So is ActiveState perl for Windows, and perl built
1632       for Apache mod_perl2.)  If you do this there are some things to keep in
1633       mind:
1634
1635       ·   If PERL_NO_GET_CONTEXT is defined, then every function that calls
1636           the Perl API will need to start out with a "dTHX;" declaration.
1637
1638       ·   You'll know which functions need this, because the C compiler will
1639           complain that the undeclared identifier "my_perl" is used if and
1640           only if the perl you are using to develop and test your driver has
1641           threads enabled.
1642
1643       ·   If you don't remember to test with a thread-enabled perl before
1644           making a release it's likely that you'll get failure reports from
1645           users who are.
1646
1647       ·   For driver private functions it is possible to gain even more
1648           efficiency by replacing "dTHX;" with "pTHX_" prepended to the
1649           parameter list and then "aTHX_" prepended to the argument list
1650           where the function is called.
1651
1652       See "How multiple interpreters and concurrency are supported" in
1653       perlguts for additional information about PERL_NO_GET_CONTEXT.
1654
1655   Implementation header dbdimp.h
1656       This header file has two jobs:
1657
1658       First it defines data structures for your private part of the handles.
1659       Note that the DBI provides many common fields for you. For example the
1660       statement handle (imp_sth) already has a row_count field with an IV
1661       type that accessed via the DBIc_ROW_COUNT(imp_sth) macro. Using this is
1662       strongly recommended as it's built in to some DBI internals so the DBI
1663       can 'just work' in more cases and you'll have less driver-specific code
1664       to write.  Study DBIXS.h to see what's included with each type of
1665       handle.
1666
1667       Second it defines macros that rename the generic names like
1668       "dbd_db_login()" to database specific names like "ora_db_login()". This
1669       avoids name clashes and enables use of different drivers when you work
1670       with a statically linked perl.
1671
1672       It also will have the important task of disabling XS methods that you
1673       don't want to implement.
1674
1675       Finally, the macros will also be used to select alternate
1676       implementations of some functions. For example, the "dbd_db_login()"
1677       function is not passed the attribute hash.
1678
1679       Since DBI v1.06, if a "dbd_db_login6()" macro is defined (for a
1680       function with 6 arguments), it will be used instead with the attribute
1681       hash passed as the sixth argument.
1682
1683       Since DBI post v1.607, if a "dbd_db_login6_sv()" macro is defined (for
1684       a function like dbd_db_login6 but with scalar pointers for the dbname,
1685       username and password), it will be used instead. This will allow your
1686       login6 function to see if there are any Unicode characters in the
1687       dbname.
1688
1689       Similarly defining dbd_db_do4_iv is preferred over dbd_db_do4,
1690       dbd_st_rows_iv over dbd_st_rows, and dbd_st_execute_iv over
1691       dbd_st_execute. The *_iv forms are declared to return the IV type
1692       instead of an int.
1693
1694       People used to just pick Oracle's dbdimp.c and use the same names,
1695       structures and types. I strongly recommend against that. At first
1696       glance this saves time, but your implementation will be less readable.
1697       It was just hell when I had to separate DBI specific parts, Oracle
1698       specific parts, mSQL specific parts and mysql specific parts in
1699       DBD::mysql's dbdimp.h and dbdimp.c. (DBD::mysql was a port of DBD::mSQL
1700       which was based on DBD::Oracle.) [Seconded, based on the experience
1701       taking DBD::Informix apart, even though the version inherited in 1996
1702       was only based on DBD::Oracle.]
1703
1704       This part of the driver is your exclusive part. Rewrite it from
1705       scratch, so it will be clean and short: in other words, a better piece
1706       of code. (Of course keep an eye on other people's work.)
1707
1708         struct imp_drh_st {
1709             dbih_drc_t com;           /* MUST be first element in structure   */
1710             /* Insert your driver handle attributes here */
1711         };
1712
1713         struct imp_dbh_st {
1714             dbih_dbc_t com;           /* MUST be first element in structure   */
1715             /* Insert your database handle attributes here */
1716         };
1717
1718         struct imp_sth_st {
1719             dbih_stc_t com;           /* MUST be first element in structure   */
1720             /* Insert your statement handle attributes here */
1721         };
1722
1723         /*  Rename functions for avoiding name clashes; prototypes are  */
1724         /*  in dbd_xsh.h                                                */
1725         #define dbd_init            drv_dr_init
1726         #define dbd_db_login6_sv    drv_db_login_sv
1727         #define dbd_db_do           drv_db_do
1728         ... many more here ...
1729
1730       These structures implement your private part of the handles.
1731
1732       You have to use the name "imp_dbh_{dr|db|st}" and the first field must
1733       be of type dbih_drc_t|_dbc_t|_stc_t and must be called "com".
1734
1735       You should never access these fields directly, except by using the
1736       DBIc_xxx() macros below.
1737
1738   Implementation source dbdimp.c
1739       Conventionally, dbdimp.c is the main implementation file (but
1740       DBD::Informix calls the file dbdimp.ec). This section includes a short
1741       note on each function that is used in the Driver.xsi template and thus
1742       has to be implemented.
1743
1744       Of course, you will probably also need to implement other support
1745       functions, which should usually be file static if they are placed in
1746       dbdimp.c. If they are placed in other files, you need to list those
1747       files in Makefile.PL (and MANIFEST) to handle them correctly.
1748
1749       It is wise to adhere to a namespace convention for your functions to
1750       avoid conflicts. For example, for a driver with prefix drv_, you might
1751       call externally visible functions dbd_drv_xxxx. You should also avoid
1752       non-constant global variables as much as possible to improve the
1753       support for threading.
1754
1755       Since Perl requires support for function prototypes (ANSI or ISO or
1756       Standard C), you should write your code using function prototypes too.
1757
1758       It is possible to use either the unmapped names such as "dbd_init()" or
1759       the mapped names such as "dbd_ix_dr_init()" in the dbdimp.c file.
1760       DBD::Informix uses the mapped names which makes it easier to identify
1761       where to look for linkage problems at runtime (which will report errors
1762       using the mapped names).
1763
1764       Most other drivers, and in particular DBD::Oracle, use the unmapped
1765       names in the source code which makes it a little easier to compare code
1766       between drivers and eases discussions on the dbi-dev mailing list.  The
1767       majority of the code fragments here will use the unmapped names.
1768
1769       Ultimately, you should provide implementations for most of the
1770       functions listed in the dbd_xsh.h header. The exceptions are optional
1771       functions (such as "dbd_st_rows()") and those functions with
1772       alternative signatures, such as "dbd_db_login6_sv", "dbd_db_login6()"
1773       and dbd_db_login(). Then you should only implement one of the
1774       alternatives, and generally the newer one of the alternatives.
1775
1776       The dbd_init method
1777
1778         #include "Driver.h"
1779
1780         DBISTATE_DECLARE;
1781
1782         void dbd_init(dbistate_t* dbistate)
1783         {
1784             DBISTATE_INIT;  /*  Initialize the DBI macros  */
1785         }
1786
1787       The "dbd_init()" function will be called when your driver is first
1788       loaded; the bootstrap command in "DBD::Driver::dr::driver()" triggers
1789       this, and the call is generated in the BOOT section of Driver.xst.
1790       These statements are needed to allow your driver to use the DBI macros.
1791       They will include your private header file dbdimp.h in turn.  Note that
1792       DBISTATE_INIT requires the name of the argument to "dbd_init()" to be
1793       called "dbistate()".
1794
1795       The dbd_drv_error method
1796
1797       You need a function to record errors so DBI can access them properly.
1798       You can call it whatever you like, but we'll call it "dbd_drv_error()"
1799       here.
1800
1801       The argument list depends on your database software; different systems
1802       provide different ways to get at error information.
1803
1804         static void dbd_drv_error(SV *h, int rc, const char *what)
1805         {
1806
1807       Note that h is a generic handle, may it be a driver handle, a database
1808       or a statement handle.
1809
1810             D_imp_xxh(h);
1811
1812       This macro will declare and initialize a variable imp_xxh with a
1813       pointer to your private handle pointer. You may cast this to to
1814       imp_drh_t, imp_dbh_t or imp_sth_t.
1815
1816       To record the error correctly, equivalent to the "set_err()" method,
1817       use one of the "DBIh_SET_ERR_CHAR(...)" or "DBIh_SET_ERR_SV(...)"
1818       macros, which were added in DBI 1.41:
1819
1820         DBIh_SET_ERR_SV(h, imp_xxh, err, errstr, state, method);
1821         DBIh_SET_ERR_CHAR(h, imp_xxh, err_c, err_i, errstr, state, method);
1822
1823       For "DBIh_SET_ERR_SV" the err, errstr, state, and method parameters are
1824       "SV*" (use &sv_undef instead of NULL).
1825
1826       For "DBIh_SET_ERR_CHAR" the err_c, errstr, state, method parameters are
1827       "char*".
1828
1829       The err_i parameter is an "IV" that's used instead of err_c if err_c is
1830       "Null".
1831
1832       The method parameter can be ignored.
1833
1834       The "DBIh_SET_ERR_CHAR" macro is usually the simplest to use when you
1835       just have an integer error code and an error message string:
1836
1837         DBIh_SET_ERR_CHAR(h, imp_xxh, Nullch, rc, what, Nullch, Nullch);
1838
1839       As you can see, any parameters that aren't relevant to you can be
1840       "Null".
1841
1842       To make drivers compatible with DBI < 1.41 you should be using
1843       dbivport.h as described in "Driver.h" above.
1844
1845       The (obsolete) macros such as "DBIh_EVENT2" should be removed from
1846       drivers.
1847
1848       The names "dbis" and "DBIS", which were used in previous versions of
1849       this document, should be replaced with the "DBIc_DBISTATE(imp_xxh)"
1850       macro.
1851
1852       The name "DBILOGFP", which was also used in previous versions of this
1853       document, should be replaced by "DBIc_LOGPIO(imp_xxh)".
1854
1855       Your code should not call the C "<stdio.h>" I/O functions; you should
1856       use "PerlIO_printf()" as shown:
1857
1858             if (DBIc_TRACE_LEVEL(imp_xxh) >= 2)
1859                 PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar %s: %s\n",
1860                     foo, neatsvpv(errstr,0));
1861
1862       That's the first time we see how tracing works within a DBI driver.
1863       Make use of this as often as you can, but don't output anything at a
1864       trace level less than 3. Levels 1 and 2 are reserved for the DBI.
1865
1866       You can define up to 8 private trace flags using the top 8 bits of
1867       "DBIc_TRACE_FLAGS(imp)", that is: 0xFF000000. See the
1868       "parse_trace_flag()" method elsewhere in this document.
1869
1870       The dbd_dr_data_sources method
1871
1872       This method is optional; the support for it was added in DBI v1.33.
1873
1874       As noted in the discussion of Driver.pm, if the data sources can be
1875       determined by pure Perl code, do it that way. If, as in DBD::Informix,
1876       the information is obtained by a C function call, then you need to
1877       define a function that matches the prototype:
1878
1879         extern AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attrs);
1880
1881       An outline implementation for DBD::Informix follows, assuming that the
1882       "sqgetdbs()" function call shown will return up to 100 databases names,
1883       with the pointers to each name in the array dbsname and the name
1884       strings themselves being stores in dbsarea.
1885
1886         AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attr)
1887         {
1888             int ndbs;
1889             int i;
1890             char *dbsname[100];
1891             char  dbsarea[10000];
1892             AV *av = Nullav;
1893
1894             if (sqgetdbs(&ndbs, dbsname, 100, dbsarea, sizeof(dbsarea)) == 0)
1895             {
1896                 av = NewAV();
1897                 av_extend(av, (I32)ndbs);
1898                 sv_2mortal((SV *)av);
1899                 for (i = 0; i < ndbs; i++)
1900                   av_store(av, i, newSVpvf("dbi:Informix:%s", dbsname[i]));
1901             }
1902             return(av);
1903         }
1904
1905       The actual DBD::Informix implementation has a number of extra lines of
1906       code, logs function entry and exit, reports the error from
1907       "sqgetdbs()", and uses "#define"'d constants for the array sizes.
1908
1909       The dbd_db_login6 method
1910
1911         int dbd_db_login6_sv(SV* dbh, imp_dbh_t* imp_dbh, SV* dbname,
1912                              SV* user, SV* auth, SV *attr);
1913
1914         or
1915
1916         int dbd_db_login6(SV* dbh, imp_dbh_t* imp_dbh, char* dbname,
1917                          char* user, char* auth, SV *attr);
1918
1919       This function will really connect to the database. The argument dbh is
1920       the database handle. imp_dbh is the pointer to the handles private
1921       data, as is imp_xxx in "dbd_drv_error()" above. The arguments dbname,
1922       user, auth and attr correspond to the arguments of the driver handle's
1923       "connect()" method.
1924
1925       You will quite often use database specific attributes here, that are
1926       specified in the DSN. I recommend you parse the DSN (using Perl) within
1927       the "connect()" method and pass the segments of the DSN via the
1928       attributes parameter through "_login()" to "dbd_db_login6()".
1929
1930       Here's how you fetch them; as an example we use hostname attribute,
1931       which can be up to 12 characters long excluding null terminator:
1932
1933         SV** svp;
1934         STRLEN len;
1935         char* hostname;
1936
1937         if ( (svp = DBD_ATTRIB_GET_SVP(attr, "drv_hostname", 12)) && SvTRUE(*svp)) {
1938             hostname = SvPV(*svp, len);
1939             DBD_ATTRIB_DELETE(attr, "drv_hostname", 12); /* avoid later STORE */
1940         } else {
1941             hostname = "localhost";
1942         }
1943
1944       If you handle any driver specific attributes in the dbd_db_login6
1945       method you probably want to delete them from "attr" (as above with
1946       DBD_ATTRIB_DELETE). If you don't delete your handled attributes DBI
1947       will call "STORE" for each attribute after the connect/login and this
1948       is at best redundant for attributes you have already processed.
1949
1950       Note: Until revision 11605 (post DBI 1.607), there was a problem with
1951       DBD_ATTRIBUTE_DELETE so unless you require a DBI version after 1.607
1952       you need to replace each DBD_ATTRIBUTE_DELETE call with:
1953
1954         hv_delete((HV*)SvRV(attr), key, key_len, G_DISCARD)
1955
1956       Note that you can also obtain standard attributes such as AutoCommit
1957       and ChopBlanks from the attributes parameter, using "DBD_ATTRIB_GET_IV"
1958       for integer attributes.
1959
1960       If, for example, your database does not support transactions but
1961       AutoCommit is set off (requesting transaction support), then you can
1962       emulate a 'failure to connect'.
1963
1964       Now you should really connect to the database. In general, if the
1965       connection fails, it is best to ensure that all allocated resources are
1966       released so that the handle does not need to be destroyed separately.
1967       If you are successful (and possibly even if you fail but you have
1968       allocated some resources), you should use the following macros:
1969
1970         DBIc_IMPSET_on(imp_dbh);
1971
1972       This indicates that the driver (implementor) has allocated resources in
1973       the imp_dbh structure and that the implementors private
1974       "dbd_db_destroy()" function should be called when the handle is
1975       destroyed.
1976
1977         DBIc_ACTIVE_on(imp_dbh);
1978
1979       This indicates that the handle has an active connection to the server
1980       and that the "dbd_db_disconnect()" function should be called before the
1981       handle is destroyed.
1982
1983       Note that if you do need to fail, you should report errors via the drh
1984       or imp_drh rather than via dbh or imp_dbh because imp_dbh will be
1985       destroyed by the failure, so errors recorded in that handle will not be
1986       visible to DBI, and hence not the user either.
1987
1988       Note too, that the function is passed dbh and imp_dbh, and there is a
1989       macro "D_imp_drh_from_dbh" which can recover the imp_drh from the
1990       imp_dbh. However, there is no DBI macro to provide you with the drh
1991       given either the imp_dbh or the dbh or the imp_drh (and there's no way
1992       to recover the dbh given just the imp_dbh).
1993
1994       This suggests that, despite the above notes about "dbd_drv_error()"
1995       taking an "SV *", it may be better to have two error routines, one
1996       taking imp_dbh and one taking imp_drh instead. With care, you can
1997       factor most of the formatting code out so that these are small routines
1998       calling a common error formatter. See the code in DBD::Informix 1.05.00
1999       for more information.
2000
2001       The "dbd_db_login6()" function should return TRUE for success, FALSE
2002       otherwise.
2003
2004       Drivers implemented long ago may define the five-argument function
2005       "dbd_db_login()" instead of "dbd_db_login6()". The missing argument is
2006       the attributes. There are ways to work around the missing attributes,
2007       but they are ungainly; it is much better to use the 6-argument form.
2008       Even later drivers will use "dbd_db_login6_sv()" which provides the
2009       dbname, username and password as SVs.
2010
2011       The dbd_db_commit and dbd_db_rollback methods
2012
2013         int dbd_db_commit(SV *dbh, imp_dbh_t *imp_dbh);
2014         int dbd_db_rollback(SV* dbh, imp_dbh_t* imp_dbh);
2015
2016       These are used for commit and rollback. They should return TRUE for
2017       success, FALSE for error.
2018
2019       The arguments dbh and imp_dbh are the same as for "dbd_db_login6()"
2020       above; I will omit describing them in what follows, as they appear
2021       always.
2022
2023       These functions should return TRUE for success, FALSE otherwise.
2024
2025       The dbd_db_disconnect method
2026
2027       This is your private part of the "disconnect()" method. Any dbh with
2028       the ACTIVE flag on must be disconnected. (Note that you have to set it
2029       in "dbd_db_connect()" above.)
2030
2031         int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);
2032
2033       The database handle will return TRUE for success, FALSE otherwise.  In
2034       any case it should do a:
2035
2036         DBIc_ACTIVE_off(imp_dbh);
2037
2038       before returning so DBI knows that "dbd_db_disconnect()" was executed.
2039
2040       Note that there's nothing to stop a dbh being disconnected while it
2041       still have active children. If your database API reacts badly to trying
2042       to use an sth in this situation then you'll need to add code like this
2043       to all sth methods:
2044
2045         if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth)))
2046           return 0;
2047
2048       Alternatively, you can add code to your driver to keep explicit track
2049       of the statement handles that exist for each database handle and
2050       arrange to destroy those handles before disconnecting from the
2051       database. There is code to do this in DBD::Informix. Similar comments
2052       apply to the driver handle keeping track of all the database handles.
2053
2054       Note that the code which destroys the subordinate handles should only
2055       release the associated database resources and mark the handles
2056       inactive; it does not attempt to free the actual handle structures.
2057
2058       This function should return TRUE for success, FALSE otherwise, but it
2059       is not clear what anything can do about a failure.
2060
2061       The dbd_db_discon_all method
2062
2063         int dbd_discon_all (SV *drh, imp_drh_t *imp_drh);
2064
2065       This function may be called at shutdown time. It should make best-
2066       efforts to disconnect all database handles - if possible. Some
2067       databases don't support that, in which case you can do nothing but
2068       return 'success'.
2069
2070       This function should return TRUE for success, FALSE otherwise, but it
2071       is not clear what anything can do about a failure.
2072
2073       The dbd_db_destroy method
2074
2075       This is your private part of the database handle destructor. Any dbh
2076       with the IMPSET flag on must be destroyed, so that you can safely free
2077       resources. (Note that you have to set it in "dbd_db_connect()" above.)
2078
2079         void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh)
2080         {
2081             DBIc_IMPSET_off(imp_dbh);
2082         }
2083
2084       The DBI Driver.xst code will have called "dbd_db_disconnect()" for you,
2085       if the handle is still 'active', before calling "dbd_db_destroy()".
2086
2087       Before returning the function must switch IMPSET to off, so DBI knows
2088       that the destructor was called.
2089
2090       A DBI handle doesn't keep references to its children. But children do
2091       keep references to their parents. So a database handle won't be
2092       "DESTROY"'d until all its children have been "DESTROY"'d.
2093
2094       The dbd_db_STORE_attrib method
2095
2096       This function handles
2097
2098         $dbh->{$key} = $value;
2099
2100       Its prototype is:
2101
2102         int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
2103                                 SV* valuesv);
2104
2105       You do not handle all attributes; on the contrary, you should not
2106       handle DBI attributes here: leave this to DBI. (There are two
2107       exceptions, AutoCommit and ChopBlanks, which you should care about.)
2108
2109       The return value is TRUE if you have handled the attribute or FALSE
2110       otherwise. If you are handling an attribute and something fails, you
2111       should call "dbd_drv_error()", so DBI can raise exceptions, if desired.
2112       If "dbd_drv_error()" returns, however, you have a problem: the user
2113       will never know about the error, because he typically will not check
2114       "$dbh->errstr()".
2115
2116       I cannot recommend a general way of going on, if "dbd_drv_error()"
2117       returns, but there are examples where even the DBI specification
2118       expects that you "croak()". (See the AutoCommit method in DBI.)
2119
2120       If you have to store attributes, you should either use your private
2121       data structure imp_xxx, the handle hash (via "(HV*)SvRV(dbh)"), or use
2122       the private imp_data.
2123
2124       The first is best for internal C values like integers or pointers and
2125       where speed is important within the driver. The handle hash is best for
2126       values the user may want to get/set via driver-specific attributes.
2127       The private imp_data is an additional "SV" attached to the handle. You
2128       could think of it as an unnamed handle attribute. It's not normally
2129       used.
2130
2131       The dbd_db_FETCH_attrib method
2132
2133       This is the counterpart of "dbd_db_STORE_attrib()", needed for:
2134
2135         $value = $dbh->{$key};
2136
2137       Its prototype is:
2138
2139         SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv);
2140
2141       Unlike all previous methods this returns an "SV" with the value. Note
2142       that you should normally execute "sv_2mortal()", if you return a
2143       nonconstant value. (Constant values are &sv_undef, &sv_no and &sv_yes.)
2144
2145       Note, that DBI implements a caching algorithm for attribute values.  If
2146       you think, that an attribute may be fetched, you store it in the dbh
2147       itself:
2148
2149         if (cacheit) /* cache value for later DBI 'quick' fetch? */
2150             hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);
2151
2152       The dbd_st_prepare method
2153
2154       This is the private part of the "prepare()" method. Note that you must
2155       not really execute the statement here. You may, however, preparse and
2156       validate the statement, or do similar things.
2157
2158         int dbd_st_prepare(SV* sth, imp_sth_t* imp_sth, char* statement,
2159                            SV* attribs);
2160
2161       A typical, simple, possibility is to do nothing and rely on the perl
2162       "prepare()" code that set the Statement attribute on the handle. This
2163       attribute can then be used by "dbd_st_execute()".
2164
2165       If the driver supports placeholders then the NUM_OF_PARAMS attribute
2166       must be set correctly by "dbd_st_prepare()":
2167
2168         DBIc_NUM_PARAMS(imp_sth) = ...
2169
2170       If you can, you should also setup attributes like NUM_OF_FIELDS, NAME,
2171       etc. here, but DBI doesn't require that - they can be deferred until
2172       execute() is called. However, if you do, document it.
2173
2174       In any case you should set the IMPSET flag, as you did in
2175       "dbd_db_connect()" above:
2176
2177         DBIc_IMPSET_on(imp_sth);
2178
2179       The dbd_st_execute method
2180
2181       This is where a statement will really be executed.
2182
2183         int dbd_st_execute(SV* sth, imp_sth_t* imp_sth);
2184
2185       "dbd_st_execute" should return -2 for any error, -1 if the number of
2186       rows affected is unknown else it should be the number of affected
2187       (updated, inserted) rows.
2188
2189       Note that you must be aware a statement may be executed repeatedly.
2190       Also, you should not expect that "finish()" will be called between two
2191       executions, so you might need code, like the following, near the start
2192       of the function:
2193
2194         if (DBIc_ACTIVE(imp_sth))
2195             dbd_st_finish(h, imp_sth);
2196
2197       If your driver supports the binding of parameters (it should!), but the
2198       database doesn't, you must do it here. This can be done as follows:
2199
2200         SV *svp;
2201         char* statement = DBD_ATTRIB_GET_PV(h, "Statement", 9, svp, "");
2202         int numParam = DBIc_NUM_PARAMS(imp_sth);
2203         int i;
2204
2205         for (i = 0; i < numParam; i++)
2206         {
2207             char* value = dbd_db_get_param(sth, imp_sth, i);
2208             /* It is your drivers task to implement dbd_db_get_param,    */
2209             /* it must be setup as a counterpart of dbd_bind_ph.         */
2210             /* Look for '?' and replace it with 'value'.  Difficult      */
2211             /* task, note that you may have question marks inside        */
2212             /* quotes and comments the like ...  :-(                     */
2213             /* See DBD::mysql for an example. (Don't look too deep into  */
2214             /* the example, you will notice where I was lazy ...)        */
2215         }
2216
2217       The next thing is to really execute the statement.
2218
2219       Note that you must set the attributes NUM_OF_FIELDS, NAME, etc when the
2220       statement is successfully executed if the driver has not already done
2221       so: they may be used even before a potential "fetchrow()".  In
2222       particular you have to tell DBI the number of fields that the statement
2223       has, because it will be used by DBI internally. Thus the function will
2224       typically ends with:
2225
2226         if (isSelectStatement) {
2227             DBIc_NUM_FIELDS(imp_sth) = numFields;
2228             DBIc_ACTIVE_on(imp_sth);
2229         }
2230
2231       It is important that the ACTIVE flag only be set for "SELECT"
2232       statements (or any other statements that can return many values from
2233       the database using a cursor-like mechanism). See "dbd_db_connect()"
2234       above for more explanations.
2235
2236       There plans for a preparse function to be provided by DBI, but this has
2237       not reached fruition yet.  Meantime, if you want to know how ugly it
2238       can get, try looking at the "dbd_ix_preparse()" in DBD::Informix
2239       dbdimp.ec and the related functions in iustoken.c and sqltoken.c.
2240
2241       The dbd_st_fetch method
2242
2243       This function fetches a row of data. The row is stored in in an array,
2244       of "SV"'s that DBI prepares for you. This has two advantages: it is
2245       fast (you even reuse the "SV"'s, so they don't have to be created after
2246       the first "fetchrow()"), and it guarantees that DBI handles
2247       "bind_cols()" for you.
2248
2249       What you do is the following:
2250
2251         AV* av;
2252         int numFields = DBIc_NUM_FIELDS(imp_sth); /* Correct, if NUM_FIELDS
2253             is constant for this statement. There are drivers where this is
2254             not the case! */
2255         int chopBlanks = DBIc_is(imp_sth, DBIcf_ChopBlanks);
2256         int i;
2257
2258         if (!fetch_new_row_of_data(...)) {
2259             ... /* check for error or end-of-data */
2260             DBIc_ACTIVE_off(imp_sth); /* turn off Active flag automatically */
2261             return Nullav;
2262         }
2263         /* get the fbav (field buffer array value) for this row       */
2264         /* it is very important to only call this after you know      */
2265         /* that you have a row of data to return.                     */
2266         av = DBIc_DBISTATE(imp_sth)->get_fbav(imp_sth);
2267         for (i = 0; i < numFields; i++) {
2268             SV* sv = fetch_a_field(..., i);
2269             if (chopBlanks && SvOK(sv) && type_is_blank_padded(field_type[i])) {
2270                 /*  Remove white space from end (only) of sv  */
2271             }
2272             sv_setsv(AvARRAY(av)[i], sv); /* Note: (re)use! */
2273         }
2274         return av;
2275
2276       There's no need to use a "fetch_a_field()" function returning an "SV*".
2277       It's more common to use your database API functions to fetch the data
2278       as character strings and use code like this:
2279
2280         sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);
2281
2282       "NULL" values must be returned as "undef". You can use code like this:
2283
2284         SvOK_off(AvARRAY(av)[i]);
2285
2286       The function returns the "AV" prepared by DBI for success or "Nullav"
2287       otherwise.
2288
2289        *FIX ME* Discuss what happens when there's no more data to fetch.
2290        Are errors permitted if another fetch occurs after the first fetch
2291        that reports no more data. (Permitted, not required.)
2292
2293       If an error occurs which leaves the $sth in a state where remaining
2294       rows can't be fetched then Active should be turned off before the
2295       method returns.
2296
2297       The dbd_st_finish3 method
2298
2299       The "$sth->finish()" method can be called if the user wishes to
2300       indicate that no more rows will be fetched even if the database has
2301       more rows to offer, and the DBI code can call the function when handles
2302       are being destroyed. See the DBI specification for more background
2303       details.
2304
2305       In both circumstances, the DBI code ends up calling the
2306       "dbd_st_finish3()" method (if you provide a mapping for
2307       "dbd_st_finish3()" in dbdimp.h), or "dbd_st_finish()" otherwise.  The
2308       difference is that "dbd_st_finish3()" takes a third argument which is
2309       an "int" with the value 1 if it is being called from a "destroy()"
2310       method and 0 otherwise.
2311
2312       Note that DBI v1.32 and earlier test on "dbd_db_finish3()" to call
2313       "dbd_st_finish3()"; if you provide "dbd_st_finish3()", either define
2314       "dbd_db_finish3()" too, or insist on DBI v1.33 or later.
2315
2316       All it needs to do is turn off the Active flag for the sth.  It will
2317       only be called by Driver.xst code, if the driver has set ACTIVE to on
2318       for the sth.
2319
2320       Outline example:
2321
2322         int dbd_st_finish3(SV* sth, imp_sth_t* imp_sth, int from_destroy) {
2323             if (DBIc_ACTIVE(imp_sth))
2324             {
2325                 /* close cursor or equivalent action */
2326                 DBIc_ACTIVE_off(imp_sth);
2327             }
2328             return 1;
2329         }
2330
2331       The from_destroy parameter is true if "dbd_st_finish3()" is being
2332       called from "DESTROY()" - and so the statement is about to be
2333       destroyed.  For many drivers there is no point in doing anything more
2334       than turning off the Active flag in this case.
2335
2336       The function returns TRUE for success, FALSE otherwise, but there isn't
2337       a lot anyone can do to recover if there is an error.
2338
2339       The dbd_st_destroy method
2340
2341       This function is the private part of the statement handle destructor.
2342
2343         void dbd_st_destroy(SV* sth, imp_sth_t* imp_sth) {
2344             ... /* any clean-up that's needed */
2345             DBIc_IMPSET_off(imp_sth); /* let DBI know we've done it   */
2346         }
2347
2348       The DBI Driver.xst code will call "dbd_st_finish()" for you, if the sth
2349       has the ACTIVE flag set, before calling "dbd_st_destroy()".
2350
2351       The dbd_st_STORE_attrib and dbd_st_FETCH_attrib methods
2352
2353       These functions correspond to "dbd_db_STORE()" and "dbd_db_FETCH()"
2354       attrib above, except that they are for statement handles.  See above.
2355
2356         int dbd_st_STORE_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv,
2357                                 SV* valuesv);
2358         SV* dbd_st_FETCH_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv);
2359
2360       The dbd_bind_ph method
2361
2362       This function is internally used by the "bind_param()" method, the
2363       "bind_param_inout()" method and by the DBI Driver.xst code if
2364       "execute()" is called with any bind parameters.
2365
2366         int dbd_bind_ph (SV *sth, imp_sth_t *imp_sth, SV *param,
2367                          SV *value, IV sql_type, SV *attribs,
2368                          int is_inout, IV maxlen);
2369
2370       The param argument holds an "IV" with the parameter number (1, 2, ...).
2371       The value argument is the parameter value and sql_type is its type.
2372
2373       If your driver does not support "bind_param_inout()" then you should
2374       ignore maxlen and croak if is_inout is TRUE.
2375
2376       If your driver does support "bind_param_inout()" then you should note
2377       that value is the "SV" after dereferencing the reference passed to
2378       "bind_param_inout()".
2379
2380       In drivers of simple databases the function will, for example, store
2381       the value in a parameter array and use it later in "dbd_st_execute()".
2382       See the DBD::mysql driver for an example.
2383
2384       Implementing bind_param_inout support
2385
2386       To provide support for parameters bound by reference rather than by
2387       value, the driver must do a number of things.  First, and most
2388       importantly, it must note the references and stash them in its own
2389       driver structure.  Secondly, when a value is bound to a column, the
2390       driver must discard any previous reference bound to the column.  On
2391       each execute, the driver must evaluate the references and internally
2392       bind the values resulting from the references.  This is only applicable
2393       if the user writes:
2394
2395         $sth->execute;
2396
2397       If the user writes:
2398
2399         $sth->execute(@values);
2400
2401       then DBI automatically calls the binding code for each element of
2402       @values.  These calls are indistinguishable from explicit user calls to
2403       "bind_param()".
2404
2405   C/XS version of Makefile.PL
2406       The Makefile.PL file for a C/XS driver is similar to the code needed
2407       for a pure Perl driver, but there are a number of extra bits of
2408       information needed by the build system.
2409
2410       For example, the attributes list passed to "WriteMakefile()" needs to
2411       specify the object files that need to be compiled and built into the
2412       shared object (DLL). This is often, but not necessarily, just dbdimp.o
2413       (unless that should be dbdimp.obj because you're building on MS
2414       Windows).
2415
2416       Note that you can reliably determine the extension of the object files
2417       from the $Config{obj_ext} values, and there are many other useful
2418       pieces of configuration information lurking in that hash.  You get
2419       access to it with:
2420
2421           use Config;
2422
2423   Methods which do not need to be written
2424       The DBI code implements the majority of the methods which are accessed
2425       using the notation "DBI->function()", the only exceptions being
2426       "DBI->connect()" and "DBI->data_sources()" which require support from
2427       the driver.
2428
2429       The DBI code implements the following documented driver, database and
2430       statement functions which do not need to be written by the DBD driver
2431       writer.
2432
2433       $dbh->do()
2434           The default implementation of this function prepares, executes and
2435           destroys the statement.  This can be replaced if there is a better
2436           way to implement this, such as "EXECUTE IMMEDIATE" which can
2437           sometimes be used if there are no parameters.
2438
2439       $h->errstr()
2440       $h->err()
2441       $h->state()
2442       $h->trace()
2443           The DBD driver does not need to worry about these routines at all.
2444
2445       $h->{ChopBlanks}
2446           This attribute needs to be honored during "fetch()" operations, but
2447           does not need to be handled by the attribute handling code.
2448
2449       $h->{RaiseError}
2450           The DBD driver does not need to worry about this attribute at all.
2451
2452       $h->{PrintError}
2453           The DBD driver does not need to worry about this attribute at all.
2454
2455       $sth->bind_col()
2456           Assuming the driver uses the "DBIc_DBISTATE(imp_xxh)->get_fbav()"
2457           function (C drivers, see below), or the "$sth->_set_fbav($data)"
2458           method (Perl drivers) the driver does not need to do anything about
2459           this routine.
2460
2461       $sth->bind_columns()
2462           Regardless of whether the driver uses
2463           "DBIc_DBISTATE(imp_xxh)->get_fbav()", the driver does not need to
2464           do anything about this routine as it simply iteratively calls
2465           "$sth->bind_col()".
2466
2467       The DBI code implements a default implementation of the following
2468       functions which do not need to be written by the DBD driver writer
2469       unless the default implementation is incorrect for the Driver.
2470
2471       $dbh->quote()
2472           This should only be written if the database does not accept the
2473           ANSI SQL standard for quoting strings, with the string enclosed in
2474           single quotes and any embedded single quotes replaced by two
2475           consecutive single quotes.
2476
2477           For the two argument form of quote, you need to implement the
2478           "type_info()" method to provide the information that quote needs.
2479
2480       $dbh->ping()
2481           This should be implemented as a simple efficient way to determine
2482           whether the connection to the database is still alive. Typically
2483           code like this:
2484
2485             sub ping {
2486                 my $dbh = shift;
2487                 $sth = $dbh->prepare_cached(q{
2488                     select * from A_TABLE_NAME where 1=0
2489                 }) or return 0;
2490                 $sth->execute or return 0;
2491                 $sth->finish;
2492                 return 1;
2493             }
2494
2495           where A_TABLE_NAME is the name of a table that always exists (such
2496           as a database system catalogue).
2497
2498       $drh->default_user
2499           The default implementation of default_user will get the database
2500           username and password fields from $ENV{DBI_USER} and
2501           $ENV{DBI_PASS}. You can override this method. It is called as
2502           follows:
2503
2504             ($user, $pass) = $drh->default_user($user, $pass, $attr)
2505

METADATA METHODS

2507       The exposition above ignores the DBI MetaData methods.  The metadata
2508       methods are all associated with a database handle.
2509
2510   Using DBI::DBD::Metadata
2511       The DBI::DBD::Metadata module is a good semi-automatic way for the
2512       developer of a DBD module to write the "get_info()" and "type_info()"
2513       functions quickly and accurately.
2514
2515       Generating the get_info method
2516
2517       Prior to DBI v1.33, this existed as the method "write_getinfo_pm()" in
2518       the DBI::DBD module. From DBI v1.33, it exists as the method
2519       "write_getinfo_pm()" in the DBI::DBD::Metadata module. This discussion
2520       assumes you have DBI v1.33 or later.
2521
2522       You examine the documentation for "write_getinfo_pm()" using:
2523
2524           perldoc DBI::DBD::Metadata
2525
2526       To use it, you need a Perl DBI driver for your database which
2527       implements the "get_info()" method. In practice, this means you need to
2528       install DBD::ODBC, an ODBC driver manager, and an ODBC driver for your
2529       database.
2530
2531       With the pre-requisites in place, you might type:
2532
2533           perl -MDBI::DBD::Metadata -we \
2534              "write_getinfo_pm (qw{ dbi:ODBC:foo_db username password Driver })"
2535
2536       The procedure writes to standard output the code that should be added
2537       to your Driver.pm file and the code that should be written to
2538       lib/DBD/Driver/GetInfo.pm.
2539
2540       You should review the output to ensure that it is sensible.
2541
2542       Generating the type_info method
2543
2544       Given the idea of the "write_getinfo_pm()" method, it was not hard to
2545       devise a parallel method, "write_typeinfo_pm()", which does the
2546       analogous job for the DBI "type_info_all()" metadata method. The
2547       "write_typeinfo_pm()" method was added to DBI v1.33.
2548
2549       You examine the documentation for "write_typeinfo_pm()" using:
2550
2551           perldoc DBI::DBD::Metadata
2552
2553       The setup is exactly analogous to the mechanism described in
2554       "Generating the get_info method".
2555
2556       With the pre-requisites in place, you might type:
2557
2558           perl -MDBI::DBD::Metadata -we \
2559              "write_typeinfo_pm (qw{ dbi:ODBC:foo_db username password Driver })"
2560
2561       The procedure writes to standard output the code that should be added
2562       to your Driver.pm file and the code that should be written to
2563       lib/DBD/Driver/TypeInfo.pm.
2564
2565       You should review the output to ensure that it is sensible.
2566
2567   Writing DBD::Driver::db::get_info
2568       If you use the DBI::DBD::Metadata module, then the code you need is
2569       generated for you.
2570
2571       If you decide not to use the DBI::DBD::Metadata module, you should
2572       probably borrow the code from a driver that has done so (eg
2573       DBD::Informix from version 1.05 onwards) and crib the code from there,
2574       or look at the code that generates that module and follow that. The
2575       method in Driver.pm will be very simple; the method in
2576       lib/DBD/Driver/GetInfo.pm is not very much more complex unless your
2577       DBMS itself is much more complex.
2578
2579       Note that some of the DBI utility methods rely on information from the
2580       "get_info()" method to perform their operations correctly. See, for
2581       example, the "quote_identifier()" and quote methods, discussed below.
2582
2583   Writing DBD::Driver::db::type_info_all
2584       If you use the "DBI::DBD::Metadata" module, then the code you need is
2585       generated for you.
2586
2587       If you decide not to use the "DBI::DBD::Metadata" module, you should
2588       probably borrow the code from a driver that has done so (eg
2589       "DBD::Informix" from version 1.05 onwards) and crib the code from
2590       there, or look at the code that generates that module and follow that.
2591       The method in Driver.pm will be very simple; the method in
2592       lib/DBD/Driver/TypeInfo.pm is not very much more complex unless your
2593       DBMS itself is much more complex.
2594
2595   Writing DBD::Driver::db::type_info
2596       The guidelines on writing this method are still not really clear.  No
2597       sample implementation is available.
2598
2599   Writing DBD::Driver::db::table_info
2600        *FIX ME* The guidelines on writing this method have not been written yet.
2601        No sample implementation is available.
2602
2603   Writing DBD::Driver::db::column_info
2604        *FIX ME* The guidelines on writing this method have not been written yet.
2605        No sample implementation is available.
2606
2607   Writing DBD::Driver::db::primary_key_info
2608        *FIX ME* The guidelines on writing this method have not been written yet.
2609        No sample implementation is available.
2610
2611   Writing DBD::Driver::db::primary_key
2612        *FIX ME* The guidelines on writing this method have not been written yet.
2613        No sample implementation is available.
2614
2615   Writing DBD::Driver::db::foreign_key_info
2616        *FIX ME* The guidelines on writing this method have not been written yet.
2617        No sample implementation is available.
2618
2619   Writing DBD::Driver::db::tables
2620       This method generates an array of names in a format suitable for being
2621       embedded in SQL statements in places where a table name is expected.
2622
2623       If your database hews close enough to the SQL standard or if you have
2624       implemented an appropriate "table_info()" function and and the
2625       appropriate "quote_identifier()" function, then the DBI default version
2626       of this method will work for your driver too.
2627
2628       Otherwise, you have to write a function yourself, such as:
2629
2630           sub tables
2631           {
2632               my($dbh, $cat, $sch, $tab, $typ) = @_;
2633               my(@res);
2634               my($sth) = $dbh->table_info($cat, $sch, $tab, $typ);
2635               my(@arr);
2636               while (@arr = $sth->fetchrow_array)
2637               {
2638                   push @res, $dbh->quote_identifier($arr[0], $arr[1], $arr[2]);
2639               }
2640               return @res;
2641           }
2642
2643       See also the default implementation in DBI.pm.
2644
2645   Writing DBD::Driver::db::quote
2646       This method takes a value and converts it into a string suitable for
2647       embedding in an SQL statement as a string literal.
2648
2649       If your DBMS accepts the SQL standard notation for strings (single
2650       quotes around the string as a whole with any embedded single quotes
2651       doubled up), then you do not need to write this method as DBI provides
2652       a default method that does it for you.
2653
2654       If your DBMS uses an alternative notation or escape mechanism, then you
2655       need to provide an equivalent function. For example, suppose your DBMS
2656       used C notation with double quotes around the string and backslashes
2657       escaping both double quotes and backslashes themselves. Then you might
2658       write the function as:
2659
2660           sub quote
2661           {
2662               my($dbh, $str) = @_;
2663               $str =~ s/["\\]/\\$&/gmo;
2664               return qq{"$str"};
2665           }
2666
2667       Handling newlines and other control characters is left as an exercise
2668       for the reader.
2669
2670       This sample method ignores the $data_type indicator which is the
2671       optional second argument to the method.
2672
2673   Writing DBD::Driver::db::quote_identifier
2674       This method is called to ensure that the name of the given table (or
2675       other database object) can be embedded into an SQL statement without
2676       danger of misinterpretation. The result string should be usable in the
2677       text of an SQL statement as the identifier for a table.
2678
2679       If your DBMS accepts the SQL standard notation for quoted identifiers
2680       (which uses double quotes around the identifier as a whole, with any
2681       embedded double quotes doubled up) and accepts "schema"."identifier"
2682       (and "catalog"."schema"."identifier" when a catalog is specified), then
2683       you do not need to write this method as DBI provides a default method
2684       that does it for you.
2685
2686       In fact, even if your DBMS does not handle exactly that notation but
2687       you have implemented the "get_info()" method and it gives the correct
2688       responses, then it will work for you. If your database is fussier, then
2689       you need to implement your own version of the function.
2690
2691       For example, DBD::Informix has to deal with an environment variable
2692       DELIMIDENT. If it is not set, then the DBMS treats names enclosed in
2693       double quotes as strings rather than names, which is usually a syntax
2694       error. Additionally, the catalog portion of the name is separated from
2695       the schema and table by a different delimiter (colon instead of dot),
2696       and the catalog portion is never enclosed in quotes. (Fortunately,
2697       valid strings for the catalog will never contain weird characters that
2698       might need to be escaped, unless you count dots, dashes, slashes and
2699       at-signs as weird.) Finally, an Informix database can contain objects
2700       that cannot be accessed because they were created by a user with the
2701       DELIMIDENT environment variable set, but the current user does not have
2702       it set. By design choice, the "quote_identifier()" method encloses
2703       those identifiers in double quotes anyway, which generally triggers a
2704       syntax error, and the metadata methods which generate lists of tables
2705       etc omit those identifiers from the result sets.
2706
2707           sub quote_identifier
2708           {
2709               my($dbh, $cat, $sch, $obj) = @_;
2710               my($rv) = "";
2711               my($qq) = (defined $ENV{DELIMIDENT}) ? '"' : '';
2712               $rv .= qq{$cat:} if (defined $cat);
2713               if (defined $sch)
2714               {
2715                   if ($sch !~ m/^\w+$/o)
2716                   {
2717                       $qq = '"';
2718                       $sch =~ s/$qq/$qq$qq/gm;
2719                   }
2720                   $rv .= qq{$qq$sch$qq.};
2721               }
2722               if (defined $obj)
2723               {
2724                   if ($obj !~ m/^\w+$/o)
2725                   {
2726                       $qq = '"';
2727                       $obj =~ s/$qq/$qq$qq/gm;
2728                   }
2729                   $rv .= qq{$qq$obj$qq};
2730               }
2731               return $rv;
2732           }
2733
2734       Handling newlines and other control characters is left as an exercise
2735       for the reader.
2736
2737       Note that there is an optional fourth parameter to this function which
2738       is a reference to a hash of attributes; this sample implementation
2739       ignores that.
2740
2741       This sample implementation also ignores the single-argument variant of
2742       the method.
2743

TRACING

2745       Tracing in DBI is controlled with a combination of a trace level and a
2746       set of flags which together are known as the trace settings. The trace
2747       settings are stored in a single integer and divided into levels and
2748       flags by a set of masks ("DBIc_TRACE_LEVEL_MASK" and
2749       "DBIc_TRACE_FLAGS_MASK").
2750
2751       Each handle has it's own trace settings and so does the DBI. When you
2752       call a method the DBI merges the handles settings into its own for the
2753       duration of the call: the trace flags of the handle are OR'd into the
2754       trace flags of the DBI, and if the handle has a higher trace level then
2755       the DBI trace level is raised to match it. The previous DBI trace
2756       settings are restored when the called method returns.
2757
2758   Trace Level
2759       The trace level is the first 4 bits of the trace settings (masked by
2760       "DBIc_TRACE_FLAGS_MASK") and represents trace levels of 1 to 15. Do not
2761       output anything at trace levels less than 3 as they are reserved for
2762       DBI.
2763
2764       For advice on what to output at each level see "Trace Levels" in DBI.
2765
2766       To test for a trace level you can use the "DBIc_TRACE_LEVEL" macro like
2767       this:
2768
2769         if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) {
2770             PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar");
2771         }
2772
2773       Also note the use of PerlIO_printf which you should always use for
2774       tracing and never the C "stdio.h" I/O functions.
2775
2776   Trace Flags
2777       Trace flags are used to enable tracing of specific activities within
2778       the DBI and drivers. The DBI defines some trace flags and drivers can
2779       define others. DBI trace flag names begin with a capital letter and
2780       driver specific names begin with a lowercase letter. For a list of DBI
2781       defined trace flags see "Trace Flags" in DBI.
2782
2783       If you want to use private trace flags you'll probably want to be able
2784       to set them by name. Drivers are expected to override the
2785       parse_trace_flag (note the singular) and check if $trace_flag_name is a
2786       driver specific trace flags and, if not, then call the DBIs default
2787       parse_trace_flag(). To do that you'll need to define a
2788       parse_trace_flag() method like this:
2789
2790         sub parse_trace_flag {
2791             my ($h, $name) = @_;
2792             return 0x01000000 if $name eq 'foo';
2793             return 0x02000000 if $name eq 'bar';
2794             return 0x04000000 if $name eq 'baz';
2795             return 0x08000000 if $name eq 'boo';
2796             return 0x10000000 if $name eq 'bop';
2797             return $h->SUPER::parse_trace_flag($name);
2798         }
2799
2800       All private flag names must be lowercase, and all private flags must be
2801       in the top 8 of the 32 bits of "DBIc_TRACE_FLAGS(imp)" i.e.,
2802       0xFF000000.
2803
2804       If you've defined a parse_trace_flag() method in ::db you'll also want
2805       it in ::st, so just alias it in:
2806
2807         *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;
2808
2809       You may want to act on the current 'SQL' trace flag that DBI defines to
2810       output SQL prepared/executed as DBI currently does not do SQL tracing.
2811
2812   Trace Macros
2813       Access to the trace level and trace flags is via a set of macros.
2814
2815         DBIc_TRACE_SETTINGS(imp) returns the trace settings
2816         DBIc_TRACE_LEVEL(imp) returns the trace level
2817         DBIc_TRACE_FLAGS(imp) returns the trace flags
2818         DBIc_TRACE(imp, flags, flaglevel, level)
2819
2820         e.g.,
2821
2822         DBIc_TRACE(imp, 0, 0, 4)
2823           if level >= 4
2824
2825         DBIc_TRACE(imp, DBDtf_FOO, 2, 4)
2826           if tracing DBDtf_FOO & level>=2 or level>=4
2827
2828         DBIc_TRACE(imp, DBDtf_FOO, 2, 0)
2829           as above but never trace just due to level
2830

WRITING AN EMULATION LAYER FOR AN OLD PERL INTERFACE

2832       Study Oraperl.pm (supplied with DBD::Oracle) and Ingperl.pm (supplied
2833       with DBD::Ingres) and the corresponding dbdimp.c files for ideas.
2834
2835       Note that the emulation code sets "$dbh->{CompatMode} = 1;" for each
2836       connection so that the internals of the driver can implement behaviour
2837       compatible with the old interface when dealing with those handles.
2838
2839   Setting emulation perl variables
2840       For example, ingperl has a $sql_rowcount variable. Rather than try to
2841       manually update this in Ingperl.pm it can be done faster in C code.  In
2842       "dbd_init()":
2843
2844         sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);
2845
2846       In the relevant places do:
2847
2848         if (DBIc_COMPAT(imp_sth))     /* only do this for compatibility mode handles */
2849             sv_setiv(sql_rowcount, the_row_count);
2850

OTHER MISCELLANEOUS INFORMATION

2852   The imp_xyz_t types
2853       Any handle has a corresponding C structure filled with private data.
2854       Some of this data is reserved for use by DBI (except for using the DBIc
2855       macros below), some is for you. See the description of the dbdimp.h
2856       file above for examples. Most functions in dbdimp.c are passed both the
2857       handle "xyz" and a pointer to "imp_xyz". In rare cases, however, you
2858       may use the following macros:
2859
2860       D_imp_dbh(dbh)
2861           Given a function argument dbh, declare a variable imp_dbh and
2862           initialize it with a pointer to the handles private data. Note:
2863           This must be a part of the function header, because it declares a
2864           variable.
2865
2866       D_imp_sth(sth)
2867           Likewise for statement handles.
2868
2869       D_imp_xxx(h)
2870           Given any handle, declare a variable imp_xxx and initialize it with
2871           a pointer to the handles private data. It is safe, for example, to
2872           cast imp_xxx to "imp_dbh_t*", if "DBIc_TYPE(imp_xxx) == DBIt_DB".
2873           (You can also call "sv_derived_from(h, "DBI::db")", but that's much
2874           slower.)
2875
2876       D_imp_dbh_from_sth
2877           Given a imp_sth, declare a variable imp_dbh and initialize it with
2878           a pointer to the parent database handle's implementors structure.
2879
2880   Using DBIc_IMPSET_on
2881       The driver code which initializes a handle should use
2882       "DBIc_IMPSET_on()" as soon as its state is such that the cleanup code
2883       must be called.  When this happens is determined by your driver code.
2884
2885       Failure to call this can lead to corruption of data structures.
2886
2887       For example, DBD::Informix maintains a linked list of database handles
2888       in the driver, and within each handle, a linked list of statements.
2889       Once a statement is added to the linked list, it is crucial that it is
2890       cleaned up (removed from the list). When DBIc_IMPSET_on() was being
2891       called too late, it was able to cause all sorts of problems.
2892
2893   Using DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off()
2894       Once upon a long time ago, the only way of handling the internal DBI
2895       boolean flags/attributes was through macros such as:
2896
2897         DBIc_WARN       DBIc_WARN_on        DBIc_WARN_off
2898         DBIc_COMPAT     DBIc_COMPAT_on      DBIc_COMPAT_off
2899
2900       Each of these took an imp_xxh pointer as an argument.
2901
2902       Since then, new attributes have been added such as ChopBlanks,
2903       RaiseError and PrintError, and these do not have the full set of
2904       macros. The approved method for handling these is now the four macros:
2905
2906         DBIc_is(imp, flag)
2907         DBIc_has(imp, flag)       an alias for DBIc_is
2908         DBIc_on(imp, flag)
2909         DBIc_off(imp, flag)
2910         DBIc_set(imp, flag, on)   set if on is true, else clear
2911
2912       Consequently, the "DBIc_XXXXX" family of macros is now mostly
2913       deprecated and new drivers should avoid using them, even though the
2914       older drivers will probably continue to do so for quite a while yet.
2915       However...
2916
2917       There is an important exception to that. The ACTIVE and IMPSET flags
2918       should be set via the "DBIc_ACTIVE_on()" and "DBIc_IMPSET_on()" macros,
2919       and unset via the "DBIc_ACTIVE_off()" and "DBIc_IMPSET_off()" macros.
2920
2921   Using the get_fbav() method
2922       THIS IS CRITICAL for C/XS drivers.
2923
2924       The "$sth->bind_col()" and "$sth->bind_columns()" documented in the DBI
2925       specification do not have to be implemented by the driver writer
2926       because DBI takes care of the details for you.
2927
2928       However, the key to ensuring that bound columns work is to call the
2929       function "DBIc_DBISTATE(imp_xxh)->get_fbav()" in the code which fetches
2930       a row of data.
2931
2932       This returns an "AV", and each element of the "AV" contains the "SV"
2933       which should be set to contain the returned data.
2934
2935       The pure Perl equivalent is the "$sth->_set_fbav($data)" method, as
2936       described in the part on pure Perl drivers.
2937
2938   Casting strings to Perl types based on a SQL type
2939       DBI from 1.611 (and DBIXS_REVISION 13606) defines the
2940       sql_type_cast_svpv method which may be used to cast a string
2941       representation of a value to a more specific Perl type based on a SQL
2942       type. You should consider using this method when processing bound
2943       column data as it provides some support for the TYPE bind_col attribute
2944       which is rarely used in drivers.
2945
2946         int sql_type_cast_svpv(pTHX_ SV *sv, int sql_type, U32 flags, void *v)
2947
2948       "sv" is what you would like cast, "sql_type" is one of the DBI defined
2949       SQL types (e.g., "SQL_INTEGER") and "flags" is a bitmask as follows:
2950
2951       DBIstcf_STRICT
2952           If set this indicates you want an error state returned if the cast
2953           cannot be performed.
2954
2955       DBIstcf_DISCARD_STRING
2956           If set and the pv portion of the "sv" is cast then this will cause
2957           sv's pv to be freed up.
2958
2959       sql_type_cast_svpv returns the following states:
2960
2961        -2 sql_type is not handled - sv not changed
2962        -1 sv is undef, sv not changed
2963         0 sv could not be cast cleanly and DBIstcf_STRICT was specified
2964         1 sv could not be case cleanly and DBIstcf_STRICT was not specified
2965         2 sv was cast ok
2966
2967       The current implementation of sql_type_cast_svpv supports
2968       "SQL_INTEGER", "SQL_DOUBLE" and "SQL_NUMERIC". "SQL_INTEGER" uses
2969       sv_2iv and hence may set IV, UV or NV depending on the number.
2970       "SQL_DOUBLE" uses sv_2nv so may set NV and "SQL_NUMERIC" will set IV or
2971       UV or NV.
2972
2973       DBIstcf_STRICT should be implemented as the StrictlyTyped attribute and
2974       DBIstcf_DISCARD_STRING implemented as the DiscardString attribute to
2975       the bind_col method and both default to off.
2976
2977       See DBD::Oracle for an example of how this is used.
2978

SUBCLASSING DBI DRIVERS

2980       This is definitely an open subject. It can be done, as demonstrated by
2981       the DBD::File driver, but it is not as simple as one might think.
2982
2983       (Note that this topic is different from subclassing the DBI. For an
2984       example of that, see the t/subclass.t file supplied with the DBI.)
2985
2986       The main problem is that the dbh's and sth's that your "connect()" and
2987       "prepare()" methods return are not instances of your DBD::Driver::db or
2988       DBD::Driver::st packages, they are not even derived from it.  Instead
2989       they are instances of the DBI::db or DBI::st classes or a derived
2990       subclass. Thus, if you write a method "mymethod()" and do a
2991
2992         $dbh->mymethod()
2993
2994       then the autoloader will search for that method in the package DBI::db.
2995       Of course you can instead to a
2996
2997         $dbh->func('mymethod')
2998
2999       and that will indeed work, even if "mymethod()" is inherited, but not
3000       without additional work. Setting @ISA is not sufficient.
3001
3002   Overwriting methods
3003       The first problem is, that the "connect()" method has no idea of
3004       subclasses. For example, you cannot implement base class and subclass
3005       in the same file: The "install_driver()" method wants to do a
3006
3007         require DBD::Driver;
3008
3009       In particular, your subclass has to be a separate driver, from the view
3010       of DBI, and you cannot share driver handles.
3011
3012       Of course that's not much of a problem. You should even be able to
3013       inherit the base classes "connect()" method. But you cannot simply
3014       overwrite the method, unless you do something like this, quoted from
3015       DBD::CSV:
3016
3017         sub connect ($$;$$$) {
3018             my ($drh, $dbname, $user, $auth, $attr) = @_;
3019
3020             my $this = $drh->DBD::File::dr::connect($dbname, $user, $auth, $attr);
3021             if (!exists($this->{csv_tables})) {
3022                 $this->{csv_tables} = {};
3023             }
3024
3025             $this;
3026         }
3027
3028       Note that we cannot do a
3029
3030         $drh->SUPER::connect($dbname, $user, $auth, $attr);
3031
3032       as we would usually do in a an OO environment, because $drh is an
3033       instance of DBI::dr. And note, that the "connect()" method of DBD::File
3034       is able to handle subclass attributes. See the description of Pure Perl
3035       drivers above.
3036
3037       It is essential that you always call superclass method in the above
3038       manner. However, that should do.
3039
3040   Attribute handling
3041       Fortunately the DBI specifications allow a simple, but still performant
3042       way of handling attributes. The idea is based on the convention that
3043       any driver uses a prefix driver_ for its private methods. Thus it's
3044       always clear whether to pass attributes to the super class or not. For
3045       example, consider this "STORE()" method from the DBD::CSV class:
3046
3047         sub STORE {
3048             my ($dbh, $attr, $val) = @_;
3049             if ($attr !~ /^driver_/) {
3050                 return $dbh->DBD::File::db::STORE($attr, $val);
3051             }
3052             if ($attr eq 'driver_foo') {
3053             ...
3054         }
3055

AUTHORS

3057       Jonathan Leffler <jleffler@us.ibm.com> (previously
3058       <jleffler@informix.com>), Jochen Wiedmann <joe@ispsoft.de>, Steffen
3059       Goeldner <sgoeldner@cpan.org>, and Tim Bunce <dbi-users@perl.org>.
3060
3061
3062
3063perl v5.32.0                      2020-07-28                       DBI::DBD(3)
Impressum