1DBI::DBD(3) User Contributed Perl Documentation DBI::DBD(3)
2
6 DBI::DBD - Perl DBI Database Driver Writer's Guide
7
9 perldoc DBI::DBD
10 Version and volatility
12 This document is still a minimal draft which is in need of further
13 work.
14 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 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 This document is a patchwork of contributions from various authors.
26 More contributions (preferably as patches) are very welcome.
27
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 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
42 The first rule for creating a new database driver for the Perl DBI is
43 very simple: DON'T!
44 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 Before deciding that you need to write a driver, do your homework to
54 ensure that you are not wasting your energies.
55 [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 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 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 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 URLs and mailing lists
74 The primary web-site for locating DBI software and information is
75 http://dbi.perl.org/
77 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 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 You should also consider monitoring the comp.lang.perl.* newsgroups,
90 especially comp.lang.perl.modules.
91 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 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 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 http://search.cpan.org/modlist/Database_Interfaces
110 Follow the DBD:: and DBIx:: links at the top to see those subsets.
112 See the DBI docs for information on DBI web sites and mailing lists.
114 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 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 This information will be recorded in the DBI module. Apart from
129 documentation purposes, registration is a prerequisite for installing
130 private methods.
131 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 This document assumes you are writing a driver called DBD::Driver, and
139 that the prefix 'drv_' is assigned to the driver.
140 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 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 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 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 Files common to pure Perl and C/XS drivers
161 Assuming that your driver is called DBD::Driver, these files are:
163 • Makefile.PL
165 • META.yml
167 • README
169 • MANIFEST
171 • Driver.pm
173 • lib/Bundle/DBD/Driver.pm
175 • lib/DBD/Driver/Summary.pm
177 • t/*.t
179 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 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 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 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 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 • Your tests should not casually modify operational databases.
213 • You should never damage existing tables in a database.
215 • 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 • At the end of a test run, there should be no testing objects left
221 behind in the database.
222 • If you create any databases, you should remove them.
224 • 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 • 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 • Document in your README file what you do, and what privileges
238 people need to do it.
239 • 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 • It is in your interests to ensure that your tests work as widely as
246 possible.
247 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 Extra files needed by C/XS drivers
256 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 • Driver.xs
261 • Driver.h
263 • dbdimp.h
265 • dbdimp.c
267 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 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 The dbdimp.h is used to specify which functions have been implemented
276 by your driver.
277 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 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 Obviously, you can add extra source code files to the list.
288 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
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 Also look carefully at DBD::AnyData and DBD::Template.
305 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 The minimal set of files we have to implement are Makefile.PL, README,
310 MANIFEST and Driver.pm.
311 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 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 Of special importance for DBI drivers is the postamble method from the
327 ExtUtils::MM_Unix man page.
328 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 Now an example, I use the word "Driver" wherever you should insert your
334 driver's name:
335 # -*- perl -*-
337 use ExtUtils::MakeMaker;
339 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 package MY;
367 sub postamble { return main::dbd_postamble(@_); }
368 sub libscan {
369 my ($self, $path) = @_;
370 ($path =~ m/\~$/) ? undef : $path;
371 }
372 Note the calls to "dbd_edit_mm_attribs()" and "dbd_postamble()".
374 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 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 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 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 All drivers must use "dbd_postamble()" or risk running into problems.
402 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 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 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 See also ExtUtils::MakeMaker and ExtUtils::MM_Unix. Consider using
424 CPAN::MakeMaker in place of ExtUtils::MakeMaker.
425 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 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 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 • 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 • 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 • Note that many people trying to install your driver will not be
452 experts in the database software.
453 • Note that many people trying to install your driver will not be
455 experts in C or Perl.
456 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 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 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 perl -MCPAN -e 'install Bundle::DBD::Driver'
470 and Perl will download, compile, test and install all the Perl modules
472 needed to build your driver.
473 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 • Listing Bundle::DBI as the main pre-requisite simplifies life.
479 • Don't forget to list your driver.
481 • Note that unless the DBMS is itself a Perl module, you cannot list
483 it as a pre-requisite in this file.
484 • You should keep the version of the bundle the same as the version
486 of your driver.
487 • You should add configuration management, copyright, and licencing
489 information at the top.
490 A suitable skeleton for this file is shown below.
492 package Bundle::DBD::Driver;
494 $VERSION = '0.01';
496 1;
498 __END__
500 =head1 NAME
502 Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules
504 =head1 SYNOPSIS
506 C<perl -MCPAN -e 'install Bundle::DBD::Driver'>
508 =head1 CONTENTS
510 Bundle::DBI - Bundle for DBI by TIMB (Tim Bunce)
512 DBD::Driver - DBD::Driver by YOU (Your Name)
514 =head1 DESCRIPTION
516 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 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 C<perl -MCPAN -e 'install Bundle::CPAN'>
527 =head1 SEE ALSO
529 Bundle::DBI
531 =head1 AUTHOR
533 Your Name E<lt>F<you@yourdomain.com>E<gt>
535 =head1 THANKS
537 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 =cut
545 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 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 It will also define three sub-packages of DBD::Driver:
560 DBD::Driver::dr
562 with methods "connect()", "data_sources()" and "disconnect_all()";
563 DBD::Driver::db
565 with methods such as "prepare()";
566 DBD::Driver::st
568 with methods such as "execute()" and "fetch()".
569 The Driver.pm file will also contain the documentation specific to
571 DBD::Driver in the format used by perldoc.
572 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 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 The DBD::Driver package
582 The header
584 package DBD::File;
586 use strict;
588 use vars qw($VERSION $drh);
589 $VERSION = "1.23.00" # Version number of DBD::File
591 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 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 For Subversion you could use:
604 $VERSION = "12.012346";
606 (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 $VERSION = "11.22";
613 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 $drh = undef; # holds driver handle once initialized
618 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 The driver constructor
623 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 sub driver
629 {
630 return $drh if $drh; # already created - return same one
631 my ($class, $attr) = @_;
632 $class .= "::dr";
634 DBD::Driver::db->install_method('drv_example_dbh_method');
636 DBD::Driver::st->install_method('drv_example_sth_method');
637 # 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 return $drh;
647 }
648 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 The prototype of "DBI::_new_drh()" is
655 $drh = DBI::_new_drh($class, $public_attrs, $private_attrs);
657 with the following arguments:
659 $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 $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 $private_attrs
671 This is another (optional) hash ref with your private attributes.
672 DBI will store them and otherwise leave them alone.
673 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 Using install_method() to expose driver-private methods
680 DBD::Foo::db->install_method($method_name, \%attr);
682 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 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 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 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 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 DBI->setup_driver('DBD::Foo');
712 before using install_method().
714 The CLONE special subroutine
716 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 sub CLONE {
724 undef $drh;
725 }
726 See
728 <http://search.cpan.org/dist/perl/pod/perlmod.pod#Making_your_module_threadsafe>
729 for details.
730 The DBD::Driver::dr package
732 The next lines of code look as follows:
734 package DBD::Driver::dr; # ====== DRIVER ======
736 $DBD::Driver::dr::imp_data_size = 0;
738 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 *FIX ME* Explain what the imp_data_size is, so that implementors aren't
744 practicing cargo-cult programming.
745 The database handle constructor
747 The database handle constructor is the driver's (hence the changed
749 namespace) "connect()" method:
750 sub connect
752 {
753 my ($drh, $dr_dsn, $user, $auth, $attr) = @_;
754 # 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 my $driver_prefix = "drv_"; # the assigned prefix for this driver
764 # 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 # 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 # 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 # 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 # 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 # create a 'blank' dbh (call superclass constructor)
793 my ($outer, $dbh) = DBI::_new_dbh($drh, { Name => $dr_dsn });
794 $dbh->STORE('Active', 1 );
796 $dbh->{drv_connection} = $connection;
797 return $outer;
799 }
800 This is mostly the same as in the driver handle constructor above. The
802 arguments are described in DBI.
803 The constructor "DBI::_new_dbh()" is called, returning a database
805 handle. The constructor's prototype is:
806 ($outer, $inner) = DBI::_new_dbh($drh, $public_attr, $private_attr);
808 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 In scalar context, only the outer handle is returned.
814 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 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 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 The data_sources() method
831 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 As a trivial example, consider a fixed list of data sources:
839 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 The disconnect_all() method
853 If you need to release any resources when the driver is unloaded, you
855 can provide a disconnect_all method.
856 Other driver handle methods
858 If you need any other driver handle methods, they can follow here.
860 Error handling
862 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 To report an error, you use the "set_err()" method:
869 $h->set_err($err, $errmsg, $state);
871 This will ensure that the error is recorded correctly and that
873 RaiseError and PrintError etc are handled correctly.
874 Typically you'll always use the method instance, aka your method's
876 first argument.
877 As "set_err()" always returns "undef" your error handling code can
879 usually be simplified to something like this:
880 return $h->set_err($err, $errmsg, $state) if ...;
882 The DBD::Driver::db package
884 package DBD::Driver::db; # ====== DATABASE ======
886 $DBD::Driver::db::imp_data_size = 0;
888 The statement handle constructor
890 There's nothing much new in the statement handle constructor, which is
892 the "prepare()" method:
893 sub prepare
895 {
896 my ($dbh, $statement, @attribs) = @_;
897 # create a 'blank' sth
899 my ($outer, $sth) = DBI::_new_sth($dbh, { Statement => $statement });
900 $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//));
902 $sth->{drv_params} = [];
904 return $outer;
906 }
907 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 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 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 Transaction handling
927 Pure Perl drivers will rarely support transactions. Thus your
929 "commit()" and "rollback()" methods will typically be quite simple:
930 sub commit
932 {
933 my ($dbh) = @_;
934 if ($dbh->FETCH('Warn')) {
935 warn("Commit ineffective while AutoCommit is on");
936 }
937 0;
938 }
939 sub rollback {
941 my ($dbh) = @_;
942 if ($dbh->FETCH('Warn')) {
943 warn("Rollback ineffective while AutoCommit is on");
944 }
945 0;
946 }
947 Or even simpler, just use the default methods provided by the DBI that
949 do nothing except return "undef".
950 The DBI's default "begin_work()" method can be used by inheritance.
952 The STORE() and FETCH() methods
954 These methods (that we have already used, see above) are called for
956 you, whenever the user does a:
957 $dbh->{$attr} = $val;
959 or, respectively,
961 $val = $dbh->{$attr};
963 See perltie for details on tied hash refs to understand why these
965 methods are required.
966 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 A good example might look like this:
973 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 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 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 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 Other database handle methods
1019 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 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 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 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 All private flag names must be lowercase, and all private flags must be
1045 in the top 8 of the 32 bits.
1046 The DBD::Driver::st package
1048 This package follows the same pattern the others do:
1050 package DBD::Driver::st;
1052 $DBD::Driver::st::imp_data_size = 0;
1054 The execute() and bind_param() methods
1056 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 We present a simplified implementation by using the drv_params
1063 attribute from above:
1064 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 sub execute
1079 {
1080 my ($sth, @bind_values) = @_;
1081 # start of by finishing any previous execution if still active
1083 $sth->finish if $sth->FETCH('Active');
1084 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 There are a number of things you should note here.
1104 We initialize the NUM_OF_FIELDS and Active attributes here, because
1106 they are essential for "bind_columns()" to work.
1107 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 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 $sth->execute() or die $sth->errstr;
1117 The execute_array(), execute_for_fetch() and bind_param_array() methods
1119 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 The following sequence describes the interaction between DBI
1125 "execute_array" and a DBD's "execute_for_fetch":
1126 1. App calls "$sth->execute_array(\%attrs, @array_of_arrays)"
1128 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 3. DBD validates and binds each array
1134 4. DBI retrieves the validated param arrays from DBD's ParamArray
1136 attribute
1137 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 6. DBD iteratively calls &$fetch_tuple_sub to retrieve parameter
1144 tuples to be added to its bulk database operation/request.
1145 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 8. DBD repeats steps 6 and 7 until all tuples are processed.
1153 E.g., here's the essence of DBD::Oracle's execute_for_fetch:
1155 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 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 Fetching data
1175 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 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 Note the use of the method "_set_fbav()" -- this is required so that
1198 "bind_col()" and "bind_columns()" work.
1199 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 The "rows()" method for this driver can be implemented like this:
1205 sub rows { shift->{drv_rows} }
1207 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 The more_results method
1214 If your driver doesn't support multiple result sets, then don't even
1216 implement this method.
1217 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 $sth->finish;
1223 then you should delete all the attributes from the attribute cache that
1225 may no longer be relevant for the new result set:
1226 delete $sth->{$_}
1228 for qw(NAME TYPE PRECISION SCALE ...);
1229 for drivers written in C use:
1231 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 Don't forget to also delete, or update, any driver-private attributes
1240 that may not be correct for the next resultset.
1241 The NUM_OF_FIELDS attribute is a special case. It should be set using
1243 STORE:
1244 $sth->STORE(NUM_OF_FIELDS => 0); /* for DBI <= 1.53 */
1246 $sth->STORE(NUM_OF_FIELDS => $new_value);
1247 for drivers written in C use this incantation:
1249 /* 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 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 Statement attributes
1264 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 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 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 my $storedNumParams = $sth->FETCH('NUM_OF_PARAMS');
1280 if (!defined $storedNumParams or $storedNumFields < 0) {
1281 $sth->STORE('NUM_OF_PARAMS') = $numParams;
1282 # Set other useful attributes that only need to be set once
1284 # for a statement, like $sth->{NAME} and $sth->{TYPE}
1285 }
1286 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 Besides that the "STORE()" and "FETCH()" methods are mainly the same as
1292 above for dbh's.
1293 Other statement methods
1295 A trivial "finish()" method to discard stored data, reset any
1297 attributes (such as Active) and do "$sth->SUPER::finish()".
1298 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 *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;
1303 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 If "DESTROY()" is called on a statement handle that's still active
1310 ("$sth->{Active}" is true) then it should effectively call "finish()".
1311 sub DESTROY {
1313 my $sth = shift;
1314 $sth->finish if $sth->FETCH('Active');
1315 }
1316 Tests
1318 The test process should conform as closely as possibly to the Perl
1319 standard test harness.
1320 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 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 When a complete file of tests must be skipped, you can provide a reason
1336 in a pseudo-comment:
1337 if ($no_transactions_available)
1339 {
1340 print "1..0 # Skip: No transactions available\n";
1341 exit 0;
1342 }
1343 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
1349 Please also see the section under "CREATING A PURE PERL DRIVER"
1350 regarding the creation of the Makefile.PL.
1351 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 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 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 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 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 • 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 • 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 • Other methods are still part of Driver.pm, but have callbacks
1385 to the XS code.
1386 • 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 For example, DBD::Informix has such a requirement, and adds the
1395 following call after the call to "_new_drh()" in Informix.pm:
1396 DBD::Informix::dr::driver_init($drh);
1398 and the following code in Informix.xs:
1400 # 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 and the code in dbdimp.h declares:
1409 extern int dbd_ix_dr_driver_init(SV *drh);
1411 and the code in dbdimp.ec (equivalent to dbdimp.c) defines:
1413 /* 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 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 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 The connect method
1435 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 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 sub connect
1446 {
1447 my ($drh, $dbname, $user, $auth, $attr) = @_;
1448 # 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 my $dbh = DBI::_new_dbh($drh, {
1455 'Name' => $dbname,
1456 })
1457 or return undef;
1458 # 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 $dbh;
1466 }
1467 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 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 DBD_ATTRIB_DELETE(attr, "my_attribute_name",
1480 strlen("my_attribute_name"));
1481 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 hv_delete((HV*)SvRV(attr), "my_attribute_name",
1487 strlen("my_attribute_name"), G_DISCARD);
1488 *FIX ME* Discuss removing attributes in Perl code.
1490 The disconnect_all method
1492 *FIX ME* T.B.S
1494 The data_sources method
1496 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 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 The prepare method
1508 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 package DBD::Driver::db; # ====== DATABASE ======
1513 use strict;
1514 sub prepare
1516 {
1517 my ($dbh, $statement, $attribs) = @_;
1518 # create a 'blank' sth
1520 my $sth = DBI::_new_sth($dbh, {
1521 'Statement' => $statement,
1522 })
1523 or return undef;
1524 # 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 The execute method
1534 *FIX ME* T.B.S
1536 The fetchrow_arrayref method
1538 *FIX ME* T.B.S
1540 Other methods?
1542 *FIX ME* T.B.S
1544 Driver.xs
1546 Driver.xs should look something like this:
1547 #include "Driver.h"
1549 DBISTATE_DECLARE;
1551 INCLUDE: Driver.xsi
1553 MODULE = DBD::Driver PACKAGE = DBD::Driver::dr
1555 /* Non-standard drh XS methods following here, if any. */
1557 /* If none (the usual case), omit the MODULE line above too. */
1558 MODULE = DBD::Driver PACKAGE = DBD::Driver::db
1560 /* 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 MODULE = DBD::Driver PACKAGE = DBD::Driver::st
1566 /* 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 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 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 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 use DBI qw(:sql_types);
1583 *FIX ME* T.B.S
1585 Driver.h
1587 Driver.h is very simple and the operational contents should look like
1588 this:
1589 #ifndef DRIVER_H_INCLUDED
1591 #define DRIVER_H_INCLUDED
1592 #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 #include <DBIXS.h> /* installed by the DBI module */
1597 #include "dbdimp.h"
1599 #include "dbivport.h" /* see below */
1601 #include <dbd_xsh.h> /* installed by the DBI module */
1603 #endif /* DRIVER_H_INCLUDED */
1605 The DBIXS.h header defines most of the interesting information that the
1607 writer of a driver needs.
1608 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 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 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 • 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 • 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 • 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 • 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 See "How multiple interpreters and concurrency are supported" in
1653 perlguts for additional information about PERL_NO_GET_CONTEXT.
1654 Implementation header dbdimp.h
1656 This header file has two jobs:
1657 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 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 It also will have the important task of disabling XS methods that you
1673 don't want to implement.
1674 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 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 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 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 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 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 struct imp_drh_st {
1709 dbih_drc_t com; /* MUST be first element in structure */
1710 /* Insert your driver handle attributes here */
1711 };
1712 struct imp_dbh_st {
1714 dbih_dbc_t com; /* MUST be first element in structure */
1715 /* Insert your database handle attributes here */
1716 };
1717 struct imp_sth_st {
1719 dbih_stc_t com; /* MUST be first element in structure */
1720 /* Insert your statement handle attributes here */
1721 };
1722 /* 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 These structures implement your private part of the handles.
1731 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 You should never access these fields directly, except by using the
1736 DBIc_xxx() macros below.
1737 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 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 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 Since Perl requires support for function prototypes (ANSI or ISO or
1756 Standard C), you should write your code using function prototypes too.
1757 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 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 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 The dbd_init method
1777 #include "Driver.h"
1779 DBISTATE_DECLARE;
1781 void dbd_init(dbistate_t* dbistate)
1783 {
1784 DBISTATE_INIT; /* Initialize the DBI macros */
1785 }
1786 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 The dbd_drv_error method
1796 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 The argument list depends on your database software; different systems
1802 provide different ways to get at error information.
1803 static void dbd_drv_error(SV *h, int rc, const char *what)
1805 {
1806 Note that h is a generic handle, may it be a driver handle, a database
1808 or a statement handle.
1809 D_imp_xxh(h);
1811 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 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 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 For "DBIh_SET_ERR_SV" the err, errstr, state, and method parameters are
1824 "SV*" (use &sv_undef instead of NULL).
1825 For "DBIh_SET_ERR_CHAR" the err_c, errstr, state, method parameters are
1827 "char*".
1828 The err_i parameter is an "IV" that's used instead of err_c if err_c is
1830 "Null".
1831 The method parameter can be ignored.
1833 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 DBIh_SET_ERR_CHAR(h, imp_xxh, Nullch, rc, what, Nullch, Nullch);
1838 As you can see, any parameters that aren't relevant to you can be
1840 "Null".
1841 To make drivers compatible with DBI < 1.41 you should be using
1843 dbivport.h as described in "Driver.h" above.
1844 The (obsolete) macros such as "DBIh_EVENT2" should be removed from
1846 drivers.
1847 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 The name "DBILOGFP", which was also used in previous versions of this
1853 document, should be replaced by "DBIc_LOGPIO(imp_xxh)".
1854 Your code should not call the C "<stdio.h>" I/O functions; you should
1856 use "PerlIO_printf()" as shown:
1857 if (DBIc_TRACE_LEVEL(imp_xxh) >= 2)
1859 PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar %s: %s\n",
1860 foo, neatsvpv(errstr,0));
1861 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 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 The dbd_dr_data_sources method
1871 This method is optional; the support for it was added in DBI v1.33.
1873 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 extern AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attrs);
1880 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 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 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 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 The dbd_db_login6 method
1910 int dbd_db_login6_sv(SV* dbh, imp_dbh_t* imp_dbh, SV* dbname,
1912 SV* user, SV* auth, SV *attr);
1913 or
1915 int dbd_db_login6(SV* dbh, imp_dbh_t* imp_dbh, char* dbname,
1917 char* user, char* auth, SV *attr);
1918 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 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 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 SV** svp;
1934 STRLEN len;
1935 char* hostname;
1936 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 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 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 hv_delete((HV*)SvRV(attr), key, key_len, G_DISCARD)
1955 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 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 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 DBIc_IMPSET_on(imp_dbh);
1971 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 DBIc_ACTIVE_on(imp_dbh);
1978 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 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 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 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 The "dbd_db_login6()" function should return TRUE for success, FALSE
2002 otherwise.
2003 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 The dbd_db_commit and dbd_db_rollback methods
2012 int dbd_db_commit(SV *dbh, imp_dbh_t *imp_dbh);
2014 int dbd_db_rollback(SV* dbh, imp_dbh_t* imp_dbh);
2015 These are used for commit and rollback. They should return TRUE for
2017 success, FALSE for error.
2018 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 These functions should return TRUE for success, FALSE otherwise.
2024 The dbd_db_disconnect method
2026 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 int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);
2032 The database handle will return TRUE for success, FALSE otherwise. In
2034 any case it should do a:
2035 DBIc_ACTIVE_off(imp_dbh);
2037 before returning so DBI knows that "dbd_db_disconnect()" was executed.
2039 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 if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth)))
2046 return 0;
2047 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 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 This function should return TRUE for success, FALSE otherwise, but it
2059 is not clear what anything can do about a failure.
2060 The dbd_db_discon_all method
2062 int dbd_discon_all (SV *drh, imp_drh_t *imp_drh);
2064 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 This function should return TRUE for success, FALSE otherwise, but it
2071 is not clear what anything can do about a failure.
2072 The dbd_db_destroy method
2074 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 void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh)
2080 {
2081 DBIc_IMPSET_off(imp_dbh);
2082 }
2083 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 Before returning the function must switch IMPSET to off, so DBI knows
2088 that the destructor was called.
2089 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 The dbd_db_STORE_attrib method
2095 This function handles
2097 $dbh->{$key} = $value;
2099 Its prototype is:
2101 int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
2103 SV* valuesv);
2104 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 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 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 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 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 The dbd_db_FETCH_attrib method
2132 This is the counterpart of "dbd_db_STORE_attrib()", needed for:
2134 $value = $dbh->{$key};
2136 Its prototype is:
2138 SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv);
2140 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 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 if (cacheit) /* cache value for later DBI 'quick' fetch? */
2150 hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);
2151 The dbd_st_prepare method
2153 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 int dbd_st_prepare(SV* sth, imp_sth_t* imp_sth, char* statement,
2159 SV* attribs);
2160 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 If the driver supports placeholders then the NUM_OF_PARAMS attribute
2166 must be set correctly by "dbd_st_prepare()":
2167 DBIc_NUM_PARAMS(imp_sth) = ...
2169 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 In any case you should set the IMPSET flag, as you did in
2175 "dbd_db_connect()" above:
2176 DBIc_IMPSET_on(imp_sth);
2178 The dbd_st_execute method
2180 This is where a statement will really be executed.
2182 int dbd_st_execute(SV* sth, imp_sth_t* imp_sth);
2184 "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 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 if (DBIc_ACTIVE(imp_sth))
2195 dbd_st_finish(h, imp_sth);
2196 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 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 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 The next thing is to really execute the statement.
2218 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 if (isSelectStatement) {
2227 DBIc_NUM_FIELDS(imp_sth) = numFields;
2228 DBIc_ACTIVE_on(imp_sth);
2229 }
2230 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 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 The dbd_st_fetch method
2242 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 What you do is the following:
2250 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 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 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 sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);
2281 "NULL" values must be returned as "undef". You can use code like this:
2283 SvOK_off(AvARRAY(av)[i]);
2285 The function returns the "AV" prepared by DBI for success or "Nullav"
2287 otherwise.
2288 *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 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 The dbd_st_finish3 method
2298 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 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 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 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 Outline example:
2321 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 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 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 The dbd_st_destroy method
2340 This function is the private part of the statement handle destructor.
2342 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 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 The dbd_st_STORE_attrib and dbd_st_FETCH_attrib methods
2352 These functions correspond to "dbd_db_STORE()" and "dbd_db_FETCH()"
2354 attrib above, except that they are for statement handles. See above.
2355 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 The dbd_bind_ph method
2361 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 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 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 If your driver does not support "bind_param_inout()" then you should
2374 ignore maxlen and croak if is_inout is TRUE.
2375 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 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 Implementing bind_param_inout support
2385 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 $sth->execute;
2396 If the user writes:
2398 $sth->execute(@values);
2400 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 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 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 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 use Config;
2422 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 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 $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 $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 $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 $h->{RaiseError}
2450 The DBD driver does not need to worry about this attribute at all.
2451 $h->{PrintError}
2453 The DBD driver does not need to worry about this attribute at all.
2454 $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 $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 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 $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 For the two argument form of quote, you need to implement the
2478 "type_info()" method to provide the information that quote needs.
2479 $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 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 where A_TABLE_NAME is the name of a table that always exists (such
2496 as a database system catalogue).
2497 $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 ($user, $pass) = $drh->default_user($user, $pass, $attr)
2505
2507 The exposition above ignores the DBI MetaData methods. The metadata
2508 methods are all associated with a database handle.
2509 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 Generating the get_info method
2516 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 You examine the documentation for "write_getinfo_pm()" using:
2523 perldoc DBI::DBD::Metadata
2525 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 With the pre-requisites in place, you might type:
2532 perl -MDBI::DBD::Metadata -we \
2534 "write_getinfo_pm (qw{ dbi:ODBC:foo_db username password Driver })"
2535 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 You should review the output to ensure that it is sensible.
2541 Generating the type_info method
2543 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 You examine the documentation for "write_typeinfo_pm()" using:
2550 perldoc DBI::DBD::Metadata
2552 The setup is exactly analogous to the mechanism described in
2554 "Generating the get_info method".
2555 With the pre-requisites in place, you might type:
2557 perl -MDBI::DBD::Metadata -we \
2559 "write_typeinfo_pm (qw{ dbi:ODBC:foo_db username password Driver })"
2560 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 You should review the output to ensure that it is sensible.
2566 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 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 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 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 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 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 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 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 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 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 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 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 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 Otherwise, you have to write a function yourself, such as:
2629 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 See also the default implementation in DBI.pm.
2644 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 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 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 sub quote
2661 {
2662 my($dbh, $str) = @_;
2663 $str =~ s/["\\]/\\$&/gmo;
2664 return qq{"$str"};
2665 }
2666 Handling newlines and other control characters is left as an exercise
2668 for the reader.
2669 This sample method ignores the $data_type indicator which is the
2671 optional second argument to the method.
2672 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 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 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 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 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 Handling newlines and other control characters is left as an exercise
2735 for the reader.
2736 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 This sample implementation also ignores the single-argument variant of
2742 the method.
2743
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 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 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 For advice on what to output at each level see "Trace Levels" in DBI.
2765 To test for a trace level you can use the "DBIc_TRACE_LEVEL" macro like
2767 this:
2768 if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) {
2770 PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar");
2771 }
2772 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 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 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 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 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 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 *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;
2808 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 Trace Macros
2813 Access to the trace level and trace flags is via a set of macros.
2814 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 e.g.,
2821 DBIc_TRACE(imp, 0, 0, 4)
2823 if level >= 4
2824 DBIc_TRACE(imp, DBDtf_FOO, 2, 4)
2826 if tracing DBDtf_FOO & level>=2 or level>=4
2827 DBIc_TRACE(imp, DBDtf_FOO, 2, 0)
2829 as above but never trace just due to level
2830
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 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 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 sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);
2845 In the relevant places do:
2847 if (DBIc_COMPAT(imp_sth)) /* only do this for compatibility mode handles */
2849 sv_setiv(sql_rowcount, the_row_count);
2850
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 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 D_imp_sth(sth)
2867 Likewise for statement handles.
2868 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 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 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 Failure to call this can lead to corruption of data structures.
2886 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 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 DBIc_WARN DBIc_WARN_on DBIc_WARN_off
2898 DBIc_COMPAT DBIc_COMPAT_on DBIc_COMPAT_off
2899 Each of these took an imp_xxh pointer as an argument.
2901 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 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 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 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 Using the get_fbav() method
2922 THIS IS CRITICAL for C/XS drivers.
2923 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 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 This returns an "AV", and each element of the "AV" contains the "SV"
2933 which should be set to contain the returned data.
2934 The pure Perl equivalent is the "$sth->_set_fbav($data)" method, as
2936 described in the part on pure Perl drivers.
2937 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 int sql_type_cast_svpv(pTHX_ SV *sv, int sql_type, U32 flags, void *v)
2947 "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 DBIstcf_STRICT
2952 If set this indicates you want an error state returned if the cast
2953 cannot be performed.
2954 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 sql_type_cast_svpv returns the following states:
2960 -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 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 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 See DBD::Oracle for an example of how this is used.
2978
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 (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 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 $dbh->mymethod()
2993 then the autoloader will search for that method in the package DBI::db.
2995 Of course you can instead to a
2996 $dbh->func('mymethod')
2998 and that will indeed work, even if "mymethod()" is inherited, but not
3000 without additional work. Setting @ISA is not sufficient.
3001 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 require DBD::Driver;
3008 In particular, your subclass has to be a separate driver, from the view
3010 of DBI, and you cannot share driver handles.
3011 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 sub connect ($$;$$$) {
3018 my ($drh, $dbname, $user, $auth, $attr) = @_;
3019 my $this = $drh->DBD::File::dr::connect($dbname, $user, $auth, $attr);
3021 if (!exists($this->{csv_tables})) {
3022 $this->{csv_tables} = {};
3023 }
3024 $this;
3026 }
3027 Note that we cannot do a
3029 $drh->SUPER::connect($dbname, $user, $auth, $attr);
3031 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 It is essential that you always call superclass method in the above
3038 manner. However, that should do.
3039 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 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
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>.
3060perl v5.34.0 2022-01-21 DBI::DBD(3)