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
14 work.
15 The changes will occur both because the DBI specification is changing
17 and hence the requirements on DBD drivers change, and because feedback
18 from people reading this document will suggest improvements to it.
19 Please read the DBI documentation first and fully, including the DBI
21 FAQ. Then reread the DBI specification again as you're reading this.
22 It'll help.
23 This document is a patchwork of contributions from various authors.
25 More contributions (preferably as patches) are very welcome.
26
28 This document is primarily intended to help people writing new database
29 drivers for the Perl Database Interface (Perl DBI). It may also help
30 others interested in discovering why the internals of a DBD driver are
31 written the way they are.
32 This is a guide. Few (if any) of the statements in it are completely
34 authoritative under all possible circumstances. This means you will
35 need to use judgement in applying the guidelines in this document. If
36 in any doubt at all, please do contact the dbi-dev mailing list
37 (details given below) where Tim Bunce and other driver authors can
38 help.
39
41 The first rule for creating a new database driver for the Perl DBI is
42 very simple: "DON'T!"
43 There is usually a driver already available for the database you want
45 to use, almost regardless of which database you choose. And very
46 often, the database will provide an ODBC driver interface, so you can
47 often use DBD::ODBC to access the database. This is typically less
48 convenient on a Unix box than on a Microsoft Windows box, but there are
49 numerous options for ODBC driver managers on Unix too, and very often
50 the ODBC driver is provided by the database supplier. Before deciding
51 that you need to write a driver, do your homework to ensure that you
52 are not wasting your energies.
53 [As of December 2002, the consensus is that if you need an ODBC driver
55 manager on Unix, then the unixODBC driver (available from
56 <http://www.unixodbc.org/>) is the way to go.]
57 The second rule for creating a new database driver for the Perl DBI is
59 also very simple: "Don't -- get someone else to do it for you!"
60 Nevertheless, there are occasions when it is necessary to write a new
62 driver, often to use a proprietary language or API to access the data‐
63 base more swiftly, or more comprehensively, than an ODBC driver can.
64 Then you should read this document very carefully, but with a suitably
65 sceptical eye. If there is something in here that does not make any
66 sense, question it. You might be right that the information is bogus.
67 But don't come to that conclusion too quickly.
68 URLs and mailing lists
70 The primary web-site for locating DBI software and information is
72 http://dbi.perl.org/
74 There are two main and one auxilliary mailing lists for people working
76 with DBI. The primary lists are dbi-users@perl.org for general users
77 of DBI and DBD drivers, and dbi-dev@perl.org mainly for DBD driver
78 writers (don't join the dbi-dev list unless you have a good reason).
79 The auxilliary list is dbi-announce@perl.org for announcing new
80 releases of DBI or DBD drivers.
81 You can join these lists by accessing the web-site
83 <http://dbi.perl.org/>. The lists are closed so you cannot send email
84 to any of the lists unless you join the list first.
85 You should also consider monitoring the comp.lang.perl.* newsgroups,
87 especially comp.lang.perl.modules.
88 The Cheetah book
90 The definitive book on Perl DBI is the Cheetah book, so called because
92 of the picture on the cover. Its proper title is 'Programming the Perl
93 DBI: Database programming with Perl' by Alligator Descartes and Tim
94 Bunce, published by O'Reilly Associates, February 2000, ISBN
95 1-56592-699-4. Buy it now if you have not already done so, and read
96 it.
97 Locating drivers
99 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
118 to establish that there is no driver already in the works. You'll do
119 that by asking the DBI mailing lists whether there is such a driver
120 available, or whether anybody is working on one.
121 When you get the go ahead, you will need to establish the name of the
123 driver and a prefix for the driver. Typically, the name is based on
124 the name of the database software it uses, and the prefix is a contrac‐
125 tion of that. Hence, DBD::Oracle has the name Oracle and the prefix
126 'ora_'. This information will be recorded in the DBI module. Apart
127 from documentation purposes, registration is a prerequisite for
128 installing private methods.
129 This document assumes you are writing a driver called DBD::Driver, and
131 that the prefix 'drv_' is assigned to the driver.
132 Two styles of database driver
134 There are two distinct styles of database driver that can be written to
136 work with the Perl DBI.
137 Your driver can be written in pure Perl, requiring no C compiler. When
139 feasible, this is the best solution, but most databases are not written
140 in such a way that this can be done. Some example pure Perl drivers
141 are DBD::File and DBD::CSV.
142 Alternatively, and most commonly, your driver will need to use some C
144 code to gain access to the database. This will be classified as a C/XS
145 driver.
146 What code will you write?
148 There are a number of files that need to be written for either a pure
150 Perl driver or a C/XS driver. There are no extra files needed only by
151 a pure Perl driver, but there are several extra files needed only by a
152 C/XS driver.
153 Files common to pure Perl and C/XS drivers
155 Assuming that your driver is called DBD::Driver, these files are:
157 * Makefile.PL
159 * README
160 * MANIFEST
161 * Driver.pm
162 * lib/Bundle/DBD/Driver.pm
163 * lib/DBD/Driver/Summary.pm
164 * t/*.t
165 The first four files are mandatory. Makefile.PL is used to control how
167 the driver is built and installed. The README file tells people who
168 download the file about how to build the module and any prerequisite
169 software that must be installed. The MANIFEST file is used by the
170 standard Perl module distribution mechanism. It lists all the source
171 files that need to be distributed with your module. Driver.pm is what
172 is loaded by the DBI code; it contains the methods peculiar to your
173 driver.
174 The lib/Bundle/DBD/Driver.pm file allows you to specify other Perl mod‐
176 ules on which yours depends in a format that allows someone to type a
177 simple command and ensure that all the pre-requisites are in place as
178 well as building your driver. The lib/DBD/Driver/Summary.pm file con‐
179 tains (an updated version of) the information that was included - or
180 that would have been included - in the appendices of the Cheetah book
181 as a summary of the abilities of your driver and the associated data‐
182 base.
183 The files in the t subdirectory are unit tests for your driver. You
185 should write your tests as stringently as possible, while taking into
186 account the diversity of installations that you can encounter. Your
187 tests should not casually modify operational databases. You should
188 never damage existing tables in a database. You should code your tests
189 to use a constrained name space within the database. For example, the
190 tables (and all other named objects) that are created could all begin
191 with 'dbd_drv_'. At the end of a test run, there should be no testing
192 objects left behind in the database. If you create any databases, you
193 should remove them. If your database supports temporary tables that
194 are automatically removed at the end of a session, then exploit them as
195 often as possible. Try to make your tests independent of each other.
196 If you have a test t/t11dowhat.t that depends upon the successful run‐
197 ning of t/t10thingamy.t, people cannot run the single test case
198 t/t11dowhat.t. Further, running t/t11dowhat.t twice in a row is likely
199 to fail (at least, if t/t11dowhat.t modifies the database at all)
200 because the database at the start of the second run is not what you saw
201 at the start of the first run. Document in your README file what you
202 do, and what privileges people need to do it. You can, and probably
203 should, sequence your tests by including a test number before an abbre‐
204 viated version of the test name; the tests are run in the order in
205 which the names are expanded by shell-style globbing.
206 Many drivers also install sub-modules DBD::Driver::SubModule for any of
208 a variety of different reasons, such as to support the metadata methods
209 (see the discussion of "METADATA METHODS" below). Such sub-modules are
210 conventionally stored in the directory lib/DBD/Driver. The module
211 itself would usually be in a file SubModule.pm. All such sub-modules
212 should themselves be version stamped (see the discussions far below).
213 Extra files needed by C/XS drivers
215 The software for a C/XS driver will typically contain at least four
217 extra files that are not relevant to a pure Perl driver.
218 * Driver.xs
220 * Driver.h
221 * dbdimp.h
222 * dbdimp.c
223 The Driver.xs file is used to generate C code that Perl can call to
225 gain access to the C functions you write that will, in turn, call down
226 onto your database software.
227 The Driver.h header is a stylized header that ensures you can access
229 the necessary Perl and DBI macros, types, and function declarations.
230 The dbdimp.h is used to specify which functions have been implemented
232 by your driver.
233 The dbdimp.c file is where you write the C code that does the real work
235 of translating between Perl-ish data types and what the database
236 expects to use and return.
237 There are some (mainly small, but very important) differences between
239 the contents of Makefile.PL and Driver.pm for pure Perl and C/XS driv‐
240 ers, so those files are described both in the section on creating a
241 pure Perl driver and in the section on creating a C/XS driver.
242 Obviously, you can add extra source code files to the list.
244 Requirements on a driver and driver writer
246 To be remotely useful, your driver must be implemented in a format that
248 allows it to be distributed via CPAN, the Comprehensive Perl Archive
249 Network (http://www.cpan.org/ and http://search.cpan.org). Of course,
250 it is easier if you do not have to meet this criterion, but you will
251 not be able to ask for much help if you do not do so, and no-one is
252 likely to want to install your module if they have to learn a new
253 installation mechanism.
254
256 Writing a pure Perl driver is surprisingly simple. However, there are
257 some problems you should be aware of. The best option is of course
258 picking up an existing driver and carefully modifying one method after
259 the other.
260 Also look carefully at DBD::AnyData and DBD::Template.
262 As an example we take a look at the DBD::File driver, a driver for
264 accessing plain files as tables, which is part of the DBD::CSV package.
265 In what follows I assume the name "Driver" for your new package and the
266 prefix 'drv_'. The minimal set of files we have to implement are Make‐
267 file.PL, README, MANIFEST and Driver.pm.
268 Pure Perl version of Makefile.PL
270 You typically start with writing "Makefile.PL", a Makefile generator.
272 The contents of this file are described in detail in the "ExtU‐
273 tils::MakeMaker" man pages. It is definitely a good idea if you start
274 reading them. At least you should know about the variables CONFIGURE,
275 DEFINED, PM, DIR, EXE_FILES, INC, LIBS, LINKTYPE, NAME, OPTIMIZE,
276 PL_FILES, VERSION, VERSION_FROM, clean, depend, realclean from the
277 "ExtUtils::MakeMaker" man page: These are used in almost any Make‐
278 file.PL. Additionally read the section on Overriding MakeMaker Methods
279 and the descriptions of the distcheck, disttest and dist targets: They
280 will definitely be useful for you.
281 Of special importance for DBI drivers is the postamble method from the
283 "ExtUtils::MM_Unix" man page. And, for Emacs users, I recommend the
284 libscan method, which removes Emacs backup files (file names which end
285 with a tilde '~') from lists of files.
286 Now an example, I use the word "Driver" wherever you should insert your
288 driver's name:
289 # -*- perl -*-
291 use DBI 1.03;
293 use DBI::DBD;
294 use ExtUtils::MakeMaker;
295 WriteMakefile(
297 dbd_edit_mm_attribs( {
298 'NAME' => 'DBD::Driver',
299 'VERSION_FROM' => 'Driver.pm',
300 'INC' => $DBI_INC_DIR,
301 'dist' => { 'SUFFIX' => '.gz',
302 'COMPRESS' => 'gzip -9f' },
303 'realclean' => { FILES => '*.xsi' },
304 },
305 { create_pp_tests => 1})
306 );
307 package MY;
309 sub postamble { return main::dbd_postamble(@_); }
310 sub libscan {
311 my ($self, $path) = @_;
312 ($path =~ m/\~$/) ? undef : $path;
313 }
314 Note the calls to "dbd_edit_mm_attribs"() and "dbd_postamble"(). The
316 second hash reference in the call to "dbd_edit_mm_attribs" (containing
317 "create_pp_tests") is optional; you should not use it unless your
318 driver is a pure Perl driver (that is, it does not use C and XS code).
319 Therefore, the call to "dbd_edit_mm_attribs" is not relevant for C/XS
320 drivers and may be omitted; simply use the (single) hash reference con‐
321 taining NAME etc as the only argument to "WriteMakefile"(). Note that
322 the "dbd_edit_mm_attribs" code will fail if you do not have a "t" sub-
323 directory containing at least one test case. All drivers must use
324 "dbd_postamble" or risk running into problems.
325 Note the specification of VERSION_FROM; the named file (Driver.pm) will
327 be scanned for the first line that looks like an assignment to $VER‐
328 SION, and the subsequent text will be used to determine the version
329 number. Note the commentary in ExtUtils::MakeMaker on the subject of
330 correctly formatted version numbers.
331 If your driver depends upon external software (it usually will), you
333 will need to add code to ensure that your environment is workable
334 before the call to "WriteMakefile"(). A full-fledged Makefile.PL can
335 be quite large (for example, the files for DBD::Oracle and
336 DBD::Informix are both over 1000 lines long, and the Informix one uses
337 - and creates - auxilliary modules too).
338 See also ExtUtils::MakeMaker and ExtUtils::MM_Unix. Consider using
340 CPAN::MakeMaker in place of ExtUtils::MakeMaker.
341 README
343 The README file should describe what the driver is for, the pre-requi‐
345 sites for the build process, the actual build process, how to report
346 errors, and who to report them to. Users will find ways of breaking
347 the driver build and test process which you would never even have
348 dreamed to be possible in your worst nightmares. Therefore, you need
349 to write this document defensively, precisely and concisely. Also, it
350 is in your interests to ensure that your tests work as widely as possi‐
351 ble. As always, use the README from one of the established drivers as
352 a basis for your own; the version in DBD::Informix is worth a look as
353 it has been quite successful in heading off problems.
354 · Note that users will have versions of Perl and DBI that are both
356 older and newer than you expected, but this will seldom cause much
357 trouble. When it does, it will be because you are using features of
358 DBI that are not supported in the version they are using.
359 · Note that users will have versions of the database software that are
361 both older and newer than you expected. You will save yourself time
362 in the long run if you can identify the range of versions which have
363 been tested and warn about versions which are not known to be OK.
364 · Note that many people trying to install your driver will not be
366 experts in the database software.
367 · Note that many people trying to install your driver will not be
369 experts in C or Perl.
370 MANIFEST
372 The MANIFEST will be used by the Makefile's dist target to build the
374 distribution tar file that is uploaded to CPAN. It should list every
375 file that you want to include in your distribution, one per line.
376 lib/Bundle/DBD/Driver.pm
378 The CPAN module provides an extremely powerful bundle mechanism that
380 allows you to specify pre-requisites for your driver. The primary pre-
381 requisite is Bundle::DBI; you may want or need to add some more. With
382 the bundle set up correctly, the user can type:
383 perl -MCPAN -e 'install Bundle::DBD::Driver'
385 and Perl will download, compile, test and install all the Perl modules
387 needed to build your driver.
388 A suitable skeleton for this file is shown below. The prerequisite
390 modules are listed in the "CONTENTS" section, with the official name of
391 the module followed by a dash and an informal name or description.
392 Listing Bundle::DBI as the main pre-requisite simplifies life. Don't
393 forget to list your driver. Note that unless the DBMS is itself a Perl
394 module, you cannot list it as a pre-requisite in this file. You should
395 keep the version of the bundle the same as the version of your driver.
396 You should add configuration management, copyright, and licencing
397 information at the top.
398 package Bundle::DBD::Driver;
400 $VERSION = '0.01';
402 1;
404 __END__
406 =head1 NAME
408 Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules
410 =head1 SYNOPSIS
412 C<perl -MCPAN -e 'install Bundle::DBD::Driver'>
414 =head1 CONTENTS
416 Bundle::DBI - Bundle for DBI by TIMB (Tim Bunce)
418 DBD::Driver - DBD::Driver by YOU (Your Name)
420 =head1 DESCRIPTION
422 This bundle includes all the modules used by the Perl Database
424 Interface (DBI) driver for Driver (DBD::Driver), assuming the
425 use of DBI version 1.13 or later, created by Tim Bunce.
426 If you've not previously used the CPAN module to install any
428 bundles, you will be interrogated during its setup phase.
429 But when you've done it once, it remembers what you told it.
430 You could start by running:
431 C<perl -MCPAN -e 'install Bundle::CPAN'>
433 =head1 SEE ALSO
435 Bundle::DBI
437 =head1 AUTHOR
439 Your Name E<lt>F<you@yourdomain.com>E<gt>
441 =head1 THANKS
443 This bundle was created by ripping off Bundle::libnet created by
445 Graham Barr E<lt>F<gbarr@ti.com>E<gt>, and radically simplified
446 with some information from Jochen Wiedmann E<lt>F<joe@ispsoft.de>E<gt>.
447 The template was then included in the DBI::DBD documentation by
448 Jonathan Leffler E<lt>F<jleffler@informix.com>E<gt>.
449 =cut
451 lib/DBD/Driver/Summary.pm
453 There is no substitute for taking the summary file from a driver that
455 was documented in the Perl book (such as DBD::Oracle or DBD::Informix
456 or DBD::ODBC, to name but three), and adapting it to describe the
457 facilities available via DBD::Driver when accessing the Driver data‐
458 base.
459 Pure Perl version of Driver.pm
461 The "Driver.pm" file defines the Perl module DBD::Driver for your
463 driver. It will define a package DBD::Driver along with some version
464 information, some variable definitions, and a function driver() which
465 will have a more or less standard structure.
466 It will also define three sub-packages of DBD::Driver:
468 DBD::Driver::dr
470 with methods connect(), data_sources() and disconnect_all();
471 DBD::Driver::db
473 with methods such as prepare();
474 DBD::Driver::st
476 with methods such as execute() and fetch().
477 The Driver.pm file will also contain the documentation specific to
479 DBD::Driver in the format used by perldoc.
480 In a pure Perl driver, the Driver.pm file is the core of the implemen‐
482 tation. You will need to provide all the key methods needed by DBI.
483 Now let's take a closer look at an excerpt of File.pm as an example.
485 We ignore things that are common to any module (even non-DBI modules)
486 or really specific to the DBD::File package.
487 The DBD::Driver package
489 The header
491 package DBD::File;
493 use strict;
495 use vars qw($VERSION $drh);
496 $VERSION = "1.23.00" # Version number of DBD::File
498 This is where the version number of your driver is specified. The code
500 in Makefile.PL is told to look in this file for the information. It is
501 recommended that you use a two-part (1.23) or three-part (1.23.45) ver‐
502 sion number. Please ensure that any other modules added with your
503 driver are also version stamped so that CPAN does not get confused.
504 Also consider the CPAN system, which gets confused and considers ver‐
505 sion 1.10 to precede version 1.9, so that using a raw CVS, RCS or SCCS
506 version number is probably not appropriate (despite being very common).
507 For RCS or CVS you can use this code:
508 $VERSION = sprintf "%d.%02d", '$Revision: 11.21 $ ' =~ /(\d+)\.(\d+)/;
510 which pads out the fractional part with leading zeros so all is well
512 (so long as you don't go past x.99)
513 $drh = undef; # holds driver handle once initialized
515 This is where the driver handle will be stored, once created. Note
517 that you may assume there is only one handle for your driver.
518 The driver constructor
520 Note that the driver method is in the DBD::Driver package, not in one
522 of the sub-packages DBD::Driver::dr, DBD::Driver::db, or
523 DBD::Driver::db.
524 sub driver
526 {
527 return $drh if $drh; # already created - return same one
528 my ($class, $attr) = @_;
529 $class .= "::dr";
531 # not a 'my' since we use it above to prevent multiple drivers
533 $drh = DBI::_new_drh($class, {
534 'Name' => 'File',
535 'Version' => $VERSION,
536 'Attribution' => 'DBD::File by Jochen Wiedmann',
537 })
538 or return undef;
539 return $drh;
541 }
542 The driver method is the driver handle constructor. It's a reasonable
544 example of how DBI implements its handles. There are three kinds:
545 driver handles (typically stored in $drh; from now on called "drh" or
546 $drh), database handles (from now on called "dbh" or $dbh) and state‐
547 ment handles (from now on called "sth" or $sth).
548 The prototype of DBI::_new_drh is
550 $drh = DBI::_new_drh($class, $public_attrs, $private_attrs);
552 with the following arguments:
554 $class
556 is typically the class for your driver, (for example,
557 "DBD::File::dr"), passed as the first argument to the driver
558 method.
559 $public_attrs
561 is a hash ref to attributes like Name, Version, and Attribution.
562 These are processed and used by DBI. You had better not make any
563 assumptions about them nor should you add private attributes here.
564 $private_attrs
566 This is another (optional) hash ref with your private attributes.
567 DBI will store them and otherwise leave them alone.
568 The DBI::new_drh method and the driver method both return "undef" for
570 failure (in which case you must look at $DBI::err and $DBI::errstr for
571 the failure information, because you have no driver handle to use).
572 The CLONE special subroutine
574 Also needed here, in the DBD::Driver package, is a CLONE() method that
576 will be called by perl when an intrepreter is cloned. All your CLONE
577 method needs to do, currently, is clear the cached $drh so the new
578 interpreter won't start using the cached $drh from the old interpreter:
579 sub CLONE {
581 undef $drh;
582 }
583 See <http://search.cpan.org/dist/perl/pod/perlmod.pod#Making_your_mod‐
585 ule_threadsafe> for details.
586 The DBD::Driver::dr package
588 The database handle constructor
590 The next lines of code look as follows:
592 package DBD::Driver::dr; # ====== DRIVER ======
594 $DBD::Driver::dr::imp_data_size = 0;
596 Note that no @ISA is needed here, or for the other DBD::Driver::*
598 classes, because the DBI takes care of that for you when the driver is
599 loaded.
600 The database handle constructor is a driver method, thus we have to
602 change the namespace.
603 sub connect
605 {
606 my ($drh, $dr_dsn, $user, $auth, $attr) = @_;
607 # Some database specific verifications, default settings
609 # and the like can go here. This should only include
610 # syntax checks or similar stuff where it's legal to
611 # 'die' in case of errors.
612 # For example, many database packages requires specific
613 # environment variables to be set; this could be where you
614 # validate that they are set, or default them if they are not set.
615 my $driver_prefix = "drv_"; # the assigned prefix for this driver
617 # Process attributes from the DSN; we assume ODBC syntax
619 # here, that is, the DSN looks like var1=val1;...;varN=valN
620 foreach my $var ( split /;/, $dr_dsn ) {
621 my ($attr_name, $attr_value) = split '=', $var, 2;
622 return $drh->set_err(1, "Can't parse DSN part '$var'")
623 unless defined $attr_value;
624 # add driver prefix to attribute name if it doesn't have it already
626 $attr_name = $driver_prefix.$attr_name
627 unless $attr_name =~ /^$driver_prefix/o;
628 # Store attribute into %$attr, replacing any existing value.
630 # The DBI will STORE() these into $dbh after we've connected
631 $attr->{$attr_name} = $attr_value;
632 }
633 # Get the attributes we'll use to connect.
635 # We use delete here because these no need to STORE them
636 my $db = delete $attr->{drv_database} ⎪⎪ delete $attr->{drv_db}
637 or return $drh->set_err(1, "No database name given in DSN '$dr_dsn'");
638 my $host = delete $attr->{drv_host} ⎪⎪ 'localhost';
639 my $port = delete $attr->{drv_port} ⎪⎪ 123456;
640 # Assume you can attach to your database via drv_connect:
642 my $connection = drv_connect($db, $host, $port, $user, $auth)
643 or return $drh->set_err(1, "Can't connect to $dr_dsn: ...");
644 # create a 'blank' dbh (call superclass constructor)
646 my ($outer, $dbh) = DBI::_new_dbh($drh, { Name => $dr_dsn });
647 $dbh->STORE('Active', 1 );
649 $dbh->{drv_connection} = $connection;
650 return $outer;
652 }
653 The Name attribute is a standard DBI attribute.
655 This is mostly the same as in the driver handle constructor above. The
657 arguments are described in the DBI man page. See DBI. The constructor
658 _new_dbh is called, returning a database handle. The constructor's
659 prototype is:
660 ($outer, $inner) = DBI::_new_dbh($drh, $public_attr, $private_attr);
662 with similar arguments to those in the driver handle constructor,
664 except that the $class is replaced by $drh.
665 In scalar context, only the outer handle is returned.
667 Note the use of the STORE method for setting the dbh attributes.
669 That's because within the driver code, the handle object you have is
670 the 'inner' handle of a tied hash, not the outer handle that the users
671 of your driver have.
672 Because you have the inner handle, tie magic doesn't get invoked when
674 you get or set values in the hash. This is often very handy for speed
675 when you want to get or set simple non-special driver-specific
676 attributes.
677 However, some attribute values, such as those handled by the DBI like
679 PrintError, don't actually exist in the hash and must be read via
680 $h->FETCH($attrib) and set via $h->STORE($attrib, $value). If in any
681 doubt, use these methods.
682 The data_sources method
684 The data_sources method must populate and return a list of valid data
686 sources, prefixed with the "dbi:Driver" incantation that allows them to
687 be used in the first argument of the "DBI->connect" method. An example
688 of this might be scanning the $HOME/.odbcini file on Unix for ODBC data
689 sources (DSNs). As a trivial example, consider a fixed list of data
690 sources:
691 sub data_sources
693 {
694 my($drh, $attr) = @_;
695 my(@list) = ();
696 # You need more sophisticated code than this to set @list...
697 push @list, "dbi:Driver:abc";
698 push @list, "dbi:Driver:def";
699 push @list, "dbi:Driver:ghi";
700 # End of code to set @list
701 return @list;
702 }
703 Error handling
705 It is quite likely that something fails in the connect method. With
707 DBD::File for example, you might catch an error when setting the cur‐
708 rent directory to something not existent by using the (driver-specific)
709 f_dir attribute.
710 To report an error, you use the "set_err" method:
712 $h->set_err($err, $errmsg, $state);
714 This will ensure that the error is recorded correctly and that RaiseEr‐
716 ror and PrintError etc are handled correctly. Typically you'll always
717 use the method instance, aka your method's first argument.
718 As set_err always returns undef your error handling code can usually be
720 simplified to something like this:
721 return $h->set_err($err, $errmsg, $state) if ...;
723 The disconnect_all method
725 If you need to release any resources when the driver is unloaded, you
727 can provide a disconnect_all method.
728 Other driver handle methods
730 If you need any other driver handle methods, they can follow here.
732 The DBD::Driver::db package
734 The statement handle constructor
736 There's nothing much new in the statement handle constructor.
738 package DBD::Driver::db; # ====== DATABASE ======
740 $DBD::Driver::db::imp_data_size = 0;
742 sub prepare
744 {
745 my ($dbh, $statement, @attribs) = @_;
746 # create a 'blank' sth
748 my ($outer, $sth) = DBI::_new_sth($dbh, { Statement => $statement });
749 $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//));
751 $sth->{drv_params} = [];
753 return $outer;
755 }
756 This is still the same: check the arguments and call the super class
758 constructor DBI::_new_sth. Again, in scalar context, only the outer
759 handle is returned. The "Statement" attribute should be cached as
760 shown.
761 Note the prefix drv_ in the attribute names: it is required that all
763 your private attributes use a lowercase prefix unique to your driver.
764 The DBI contains a registry of known driver prefixes and may one day
765 warn about unknown attributes that don't have a registered prefix.
766 Note that we parse the statement here in order to set the attribute
768 NUM_OF_PARAMS. The technique illustrated is not very reliable; it can
769 be confused by question marks appearing in quoted strings, delimited
770 identifiers or in SQL comments that are part of the SQL statement. We
771 could set NUM_OF_PARAMS in the execute method instead because the DBI
772 specification explicitly allows a driver to defer this, but then the
773 user could not call bind_param.
774 Transaction handling
776 Pure Perl drivers will rarely support transactions. Thus your commit
778 and rollback methods will typically be quite simple:
779 sub commit
781 {
782 my ($dbh) = @_;
783 if ($dbh->FETCH('Warn')) {
784 warn("Commit ineffective while AutoCommit is on");
785 }
786 0;
787 }
788 sub rollback {
790 my ($dbh) = @_;
791 if ($dbh->FETCH('Warn')) {
792 warn("Rollback ineffective while AutoCommit is on");
793 }
794 0;
795 }
796 Or even simpler, just use the default methods provided by the DBI that
798 do nothing except return undef.
799 The DBI's default begin_work method can be used by inheritance.
801 The STORE and FETCH methods
803 These methods (that we have already used, see above) are called for
805 you, whenever the user does a:
806 $dbh->{$attr} = $val;
808 or, respectively,
810 $val = $dbh->{$attr};
812 See perltie for details on tied hash refs to understand why these meth‐
814 ods are required.
815 The DBI will handle most attributes for you, in particular attributes
817 like RaiseError or PrintError. All you have to do is handle your
818 driver's private attributes and any attributes, like AutoCommit and
819 ChopBlanks, that the DBI can't handle for you. A good example might
820 look like this:
821 sub STORE
823 {
824 my ($dbh, $attr, $val) = @_;
825 if ($attr eq 'AutoCommit') {
826 # AutoCommit is currently the only standard attribute we have
827 # to consider.
828 if (!$val) { die "Can't disable AutoCommit"; }
829 return 1;
830 }
831 if ($attr =~ m/^drv_/) {
832 # Handle only our private attributes here
833 # Note that we could trigger arbitrary actions.
834 # Ideally we should warn about unknown attributes.
835 $dbh->{$attr} = $val; # Yes, we are allowed to do this,
836 return 1; # but only for our private attributes
837 }
838 # Else pass up to DBI to handle for us
839 $dbh->SUPER::STORE($attr, $val);
840 }
841 sub FETCH
843 {
844 my ($dbh, $attr) = @_;
845 if ($attr eq 'AutoCommit') { return 1; }
846 if ($attr =~ m/^drv_/) {
847 # Handle only our private attributes here
848 # Note that we could trigger arbitrary actions.
849 return $dbh->{$attr}; # Yes, we are allowed to do this,
850 # but only for our private attributes
851 }
852 # Else pass up to DBI to handle
853 $dbh->SUPER::FETCH($attr);
854 }
855 The DBI will actually store and fetch driver-specific attributes (with
857 all lowercase names) without warning or error, so there's actually no
858 need to implement driver-specific any code in your FETCH and STORE
859 methods unless you need extra logic/checks, beyond getting or setting
860 the value.
861 Unless your driver documentation indicates otherwise, the return value
863 of the STORE method is unspecified and the caller shouldn't use that
864 value.
865 Other database handle methods
867 As with the driver package, other database handle methods may follow
869 here. In particular you should consider a (possibly empty) disconnect
870 method and possibly a quote method if DBI's default isn't correct for
871 you.
872 Where reasonable use $h->SUPER::foo() to call the DBI's method in some
874 or all cases and just wrap your custom behavior around that.
875 If you want to use private trace flags you'll probably want to be able
877 to set them by name. To do that you'll need to define a
878 parse_trace_flag() method (note that's parse_trace_flag not
879 parse_trace_flags).
880 sub parse_trace_flag {
882 my ($h, $name) = @_;
883 return 0x01000000 if $name eq 'foo';
884 return 0x02000000 if $name eq 'bar';
885 return 0x04000000 if $name eq 'baz';
886 return 0x08000000 if $name eq 'boo';
887 return 0x10000000 if $name eq 'bop';
888 return $h->SUPER::parse_trace_flag($name);
889 }
890 All private flag names must be lowercase, and all private flags must be
892 in the top 8 of the 32 bits.
893 The DBD::Driver::st package
895 The execute method
897 This is perhaps the most difficult method because we have to consider
899 parameter bindings here. We present a simplified implementation by
900 using the drv_params attribute from above:
901 package DBD::Driver::st;
903 $DBD::Driver::st::imp_data_size = 0;
905 sub bind_param
907 {
908 my ($sth, $pNum, $val, $attr) = @_;
909 my $type = (ref $attr) ? $attr->{TYPE} : $attr;
910 if ($type) {
911 my $dbh = $sth->{Database};
912 $val = $dbh->quote($sth, $type);
913 }
914 my $params = $sth->{drv_params};
915 $params->[$pNum-1] = $val;
916 1;
917 }
918 sub execute
920 {
921 my ($sth, @bind_values) = @_;
922 # start of by finishing any previous execution if still active
924 $sth->finish if $sth->FETCH('Active');
925 my $params = (@bind_values) ?
927 \@bind_values : $sth->{drv_params};
928 my $numParam = $sth->FETCH('NUM_OF_PARAMS');
929 return $sth->set_err(1, "Wrong number of parameters")
930 if @$params != $numParam;
931 my $statement = $sth->{'Statement'};
932 for (my $i = 0; $i < $numParam; $i++) {
933 $statement =~ s/?/$params->[$i]/; # XXX doesn't deal with quoting etc!
934 }
935 # Do anything ... we assume that an array ref of rows is
936 # created and store it:
937 $sth->{'drv_data'} = $data;
938 $sth->{'drv_rows'} = @$data; # number of rows
939 $sth->STORE('NUM_OF_FIELDS') = $numFields;
940 @$data ⎪⎪ '0E0';
941 }
942 There are a number of things you should note here. We setup the
944 NUM_OF_FIELDS attribute here, because this is essential for bind_col‐
945 umns to work. We use attribute "$sth->{Statement}" which we created
946 within prepare. The attribute "$sth->{Database}", which is nothing else
947 than the dbh, was automatically created by DBI.
948 Finally note that (as specified in the DBI specification) we return the
950 string '0E0' instead of the number 0, so that the result tests true but
951 equal to zero.
952 $sth->execute() or die $sth->errstr;
954 Fetching data
956 We should not implement the methods fetchrow_array, fetchall_arrayref,
958 ... because these are already part of DBI. All we need is the method
959 fetchrow_arrayref:
960 sub fetchrow_arrayref
962 {
963 my ($sth) = @_;
964 my $data = $sth->{drv_data};
965 my $row = shift @$data;
966 if (!$row) {
967 $sth->STORE(Active => 0); # mark as no longer active
968 return undef;
969 }
970 if ($sth->FETCH('ChopBlanks')) {
971 map { $_ =~ s/\s+$//; } @$row;
972 }
973 return $sth->_set_fbav($row);
974 }
975 *fetch = \&fetchrow_arrayref; # required alias for fetchrow_arrayref
976 Note the use of the method _set_fbav: This is required so that bind_col
978 and bind_columns work.
979 If an error occurs which leaves the $sth in a state where remaining
981 rows can't be fetched then Active should be turned off before the
982 method returns.
983 The rows method for this driver can be implemented like this:
985 sub rows { shift->{drv_rows} }
987 because it knows in advance how many rows it has fetched. Alterna‐
989 tively you could delete that method and so fallback to the DBI's own
990 method which does the right thing based on the number of calls to
991 _set_fbav().
992 Statement attributes
994 The main difference between dbh and sth attributes is, that you should
996 implement a lot of attributes here that are required by the DBI, such
997 as NAME, NULLABLE, TYPE, ...
998 Besides that the STORE and FETCH methods are mainly the same as above
1000 for dbh's.
1001 Other statement methods
1003 A trivial "finish" method to discard the stored data and do
1005 $sth->SUPER::finish;
1006 If you've defined a parse_trace_flag() method in ::db you'll also want
1008 it in ::st, so just alias it in:
1009 *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;
1011 And perhaps some other methods that are not part of the DBI specifica‐
1013 tion, in particular to make metadata available. Remember that they
1014 must have names that begin with your drivers registered prefix so they
1015 can be installed using install_method().
1016 If DESTROY() is called on a statement handle that's still active
1018 ($sth->{Active} is true) then it should effectively call finish().
1019 sub DESTROY {
1021 my $sth = shift;
1022 $sth->finish if $sth->FETCH('Active');
1023 }
1024 Tests
1026 The test process should conform as closely as possibly to the Perl
1028 standard test harness.
1029 In particular, most (all) of the tests should be run in the t
1031 sub-directory, and should simply produce an 'ok' when run under 'make
1032 test'. For details on how this is done, see the Camel book and the
1033 section in Chapter 7, "The Standard Perl Library" on Test::Harness.
1034 The tests may need to adapt to the type of database which is being used
1036 for testing, and to the privileges of the user testing the driver.
1037 The DBD::Informix test code has to adapt in a number of places to the
1039 type of database to which it is connected as different Informix data‐
1040 bases have different capabilities. For example, some of the tests are
1041 for databases without transaction logs; others are for databases with a
1042 transaction log. Some versions of the server have support for blobs,
1043 or stored procedures, or user-defined data types, and others do not.
1044 When a complete file of tests must be skipped, you can provide a reason
1045 in a pseudo-comment:
1046 if ($no_transactions_available)
1048 {
1049 print "1..0 # Skip: No transactions available\n";
1050 exit 0;
1051 }
1052 Consider downloading the DBD::Informix code and look at the code in
1054 DBD/Informix/TestHarness.pm which is used throughout the DBD::Informix
1055 tests in the t sub-directory.
1056
1058 Creating a new C/XS driver from scratch will always be a daunting task.
1059 You can and should greatly simplify your task by taking a good refer‐
1060 ence driver implementation and modifying that to match the database
1061 product for which you are writing a driver.
1062 The de facto reference driver has been the one for DBD::Oracle written
1064 by Tim Bunce, who is also the author of the DBI package. The DBD::Ora‐
1065 cle module is a good example of a driver implemented around a C-level
1066 API.
1067 Nowadays it it seems better to base on DBD::ODBC, another driver main‐
1069 tained by Tim and Jeff Urlwin, because it offers a lot of metadata and
1070 seems to become the guideline for the future development. (Also as
1071 DBD::Oracle digs deeper into the Oracle 8 OCI interface it'll get even
1072 more hairy than it is now.)
1073 The DBD::Informix driver is one driver implemented using embedded SQL
1075 instead of a function-based API. DBD::Ingres may also be worth a look.
1076 C/XS version of Driver.pm
1078 A lot of the code in the Driver.pm file is very similar to the code for
1080 pure Perl modules - see above. However, there are also some subtle
1081 (and not so subtle) differences, including:
1082 · The variables $DBD::File::{dr⎪db⎪st}::imp_data_size are not
1084 defined here, but in the XS code, because they declare the size
1085 of certain C structures.
1086 · Some methods are typically moved to the XS code, in particular
1088 prepare, execute, disconnect, disconnect_all and the STORE and
1089 FETCH methods.
1090 · Other methods are still part of "Driver.pm", but have callbacks
1092 to the XS code.
1093 · If the driver-specific parts of the imp_drh_t structure need to
1095 be formally initialized (which does not seem to be a common
1096 requirement), then you need to add a call to an appropriate XS
1097 function in the driver method of DBD::Driver::driver, and you
1098 define the corresponding function in Driver.xs, and you define
1099 the C code in dbdimp.c and the prototype in dbdimp.h.
1100 For example, DBD::Informix has such a requirement, and adds the
1102 following call after the call to _new_drh in Informix.pm:
1103 DBD::Informix::dr::driver_init($drh);
1105 and the following code in Informix.xs:
1107 # Initialize the DBD::Informix driver data structure
1109 void
1110 driver_init(drh)
1111 SV *drh
1112 CODE:
1113 ST(0) = dbd_ix_dr_driver_init(drh) ? &sv_yes : &sv_no;
1114 and the code in dbdimp.h declares:
1116 extern int dbd_ix_dr_driver_init(SV *drh);
1118 and the code in dbdimp.ec (equivalent to dbdimp.c) defines:
1120 /* Formally initialize the DBD::Informix driver structure */
1122 int
1123 dbd_ix_dr_driver(SV *drh)
1124 {
1125 D_imp_drh(drh);
1126 imp_drh->n_connections = 0; /* No active connections */
1127 imp_drh->current_connection = 0; /* No current connection */
1128 imp_drh->multipleconnections = (ESQLC_VERSION >= 600) ? True : False;
1129 dbd_ix_link_newhead(&imp_drh->head); /* Empty linked list of connections */
1130 return 1;
1131 }
1132 DBD::Oracle has a similar requirement but gets around it by
1134 checking whether the private data part of the driver handle is
1135 all zeroed out, rather than add extra functions.
1136 Now let's take a closer look at an excerpt from Oracle.pm (revised
1138 heavily to remove idiosyncrasies) as an example. We also ignore things
1139 that are already discussed for pure Perl drivers.
1140 The connect method
1142 The connect method is the database handle constructor. You could write
1144 either of two versions of this method: either one which takes connec‐
1145 tion attributes (new code) and one which ignores them (old code only).
1146 If you ignore the connection attributes, then you omit all mention of
1147 the $auth variable (which is a reference to a hash of attributes), and
1148 the XS system manages the differences for you.
1149 sub connect
1151 {
1152 my ($drh, $dbname, $user, $auth, $attr) = @_;
1153 # Some database specific verifications, default settings
1155 # and the like following here. This should only include
1156 # syntax checks or similar stuff where it's legal to
1157 # 'die' in case of errors.
1158 my $dbh = DBI::_new_dbh($drh, {
1160 'Name' => $dbname,
1161 })
1162 or return undef;
1163 # Call the driver-specific function _login in Driver.xs file which
1165 # calls the DBMS-specific function(s) to connect to the database,
1166 # and populate internal handle data.
1167 DBD::Driver::db::_login($dbh, $dbname, $user, $auth, $attr)
1168 or return undef;
1169 $dbh;
1171 }
1172 This is mostly the same as in the pure Perl case, the exception being
1174 the use of the private _login callback, which is the function that will
1175 really connect to the database. It is implemented in Driver.xst (you
1176 should not implement it) and calls dbd_db_login6 from dbdimp.c. See
1177 below for details.
1178 *FIX ME* Discuss removing attributes from hash reference as an optimization
1180 to skip later calls to $dbh->STORE made by DBI->connect.
1181 *FIX ME* Discuss removing attributes in Perl code.
1183 *FIX ME* Discuss removing attributes in C code.
1185 The disconnect_all method
1187 *FIX ME* T.B.S
1189 The data_sources method
1191 If your data_sources method can be implemented in pure Perl, then do so
1193 because it is easier than doing it in XS code (see the section above
1194 for pure Perl drivers). If your data_sources method must call onto
1195 compiled functions, then you will need to define dbd_dr_data_sources in
1196 your dbdimp.h file, which will trigger Driver.xst (in DBI v1.33 or
1197 greater) to generate the XS code that calls your actual C function (see
1198 the discussion below for details) and you do not code anything in
1199 Driver.pm to handle it.
1200 The prepare method
1202 The prepare method is the statement handle constructor, and most of it
1204 is not new. Like the connect method, it now has a C callback:
1205 package DBD::Driver::db; # ====== DATABASE ======
1207 use strict;
1208 sub prepare
1210 {
1211 my ($dbh, $statement, $attribs) = @_;
1212 # create a 'blank' sth
1214 my $sth = DBI::_new_sth($dbh, {
1215 'Statement' => $statement,
1216 })
1217 or return undef;
1218 # Call the driver-specific function _prepare in Driver.xs file
1220 # which calls the DBMS-specific function(s) to prepare a statement
1221 # and populate internal handle data.
1222 DBD::Driver::st::_prepare($sth, $statement, $attribs)
1223 or return undef;
1224 $sth;
1225 }
1226 The execute method
1228 *FIX ME* T.B.S
1230 The fetchrow_arrayref method
1232 *FIX ME* T.B.S
1234 Other methods?
1236 *FIX ME* T.B.S
1238 Driver.xs
1240 Driver.xs should look something like this:
1242 #include "Driver.h"
1244 DBISTATE_DECLARE;
1246 INCLUDE: Driver.xsi
1248 MODULE = DBD::Driver PACKAGE = DBD::Driver::dr
1250 /* Non-standard drh XS methods following here, if any. */
1252 /* If none (the usual case), omit the MODULE line above too. */
1253 MODULE = DBD::Driver PACKAGE = DBD::Driver::db
1255 /* Non-standard dbh XS methods following here, if any. */
1257 /* Currently this includes things like _list_tables from */
1258 /* DBD::mSQL and DBD::mysql. */
1259 MODULE = DBD::Driver PACKAGE = DBD::Driver::st
1261 /* Non-standard sth XS methods following here, if any. */
1263 /* In particular this includes things like _list_fields from */
1264 /* DBD::mSQL and DBD::mysql for accessing metadata. */
1265 Note especially the include of Driver.xsi here: DBI inserts stub func‐
1267 tions for almost all private methods here which will typically do much
1268 work for you. Wherever you really have to implement something, it will
1269 call a private function in dbdimp.c, and this is what you have to
1270 implement.
1271 You need to set up an extra routine if your driver needs to export con‐
1273 stants of its own, analogous to the SQL types available when you say:
1274 use DBI qw(:sql_types);
1276 *FIX ME* T.B.S
1278 Driver.h
1280 Driver.h is very simple and the operational contents should look like
1282 this:
1283 #ifndef DRIVER_H_INCLUDED
1285 #define DRIVER_H_INCLUDED
1286 #define NEED_DBIXS_VERSION 93 /* 93 for DBI versions 1.00 to 1.51+ */
1288 #define PERL_NO_GET_CONTEXT /* if used require DBI 1.51+ */
1289 #include <DBIXS.h> /* installed by the DBI module */
1291 #include "dbdimp.h"
1293 #include "dbivport.h" /* see below */
1295 #include <dbd_xsh.h> /* installed by the DBI module */
1297 #endif /* DRIVER_H_INCLUDED */
1299 The "DBIXS.h" header defines most of the interesting information that
1301 the writer of a driver needs. The file "dbd_xsh.h" header provides
1302 prototype declarations for the C functions that you might decide to
1303 implement. Note that you should normally only define one of
1304 dbd_db_login and dbd_db_login6 unless you are intent on supporting
1305 really old versions of DBI (prior to DBI 1.06) as well as modern ver‐
1306 sions. The only standard, DBI-mandated functions that you need write
1307 are those specified in the dbd_xsh.h header. You might also add extra
1308 driver-specific functions in Driver.xs.
1309 The dbivport.h file should be copied from the latest DBI release into
1311 your distribution each time you enhance your driver to use new features
1312 for which the DBI is offering backwards compatibility via dbivport.h.
1313 Its job is to allow you to enhance your code to work with the latest
1315 DBI API while still allowing your driver to be compiled and used with
1316 older versions of the DBI. For example, when the DBIh_SET_ERR_CHAR
1317 macro was added to DBI 1.41 in an emulation of it was added to dbiv‐
1318 port.h.
1319 Copying dbivport.h into your driver distribution and #including it in
1321 Driver.h, as shown above, lets you enhance your driver to use the new
1322 DBIh_SET_ERR_CHAR macro even with versions of the DBI earlier than
1323 1.41. This makes users happy and your life easier.
1324 Always read the notes in dbivport.h to check for any limitations in the
1326 emulation that you should be aware of.
1327 With DBI v1.51 or better I recommend that the driver defines
1329 PERL_NO_GET_CONTEXT before DBIXS.h is included. This can significantly
1330 improve efficiency when running under a thread enabled perl. (Remember
1331 that the standard perl in most Linux distributions is built with
1332 threads enabled. So is ActiveState perl for Windows, and perl built
1333 for Apache mod_perl2.) If you do this there are some things to keep in
1334 mind:
1335 * If PERL_NO_GET_CONTEXT is defined, then every function that calls the
1337 Perl API will need to start out with a "dTHX;" declaration.
1338 * You'll know which functions need this, because the C compiler will
1340 complain that the undeclared identifier "my_perl" is used if and only
1341 if the perl you are using to develop and test your driver has threads
1342 enabled.
1343 * So if you don't remember to test with a thread-enabled perl before
1345 making a release it's likely that you'll get failure reports from users
1346 who are.
1347 * For driver private functions it is possible to gain even more effi‐
1349 ciency by replacing "dTHX;" with "pTHX_" prepended to the parameter
1350 list and then "aTHX_" prepended to the argument list where the function
1351 is called.
1352 See "How multiple interpreters and concurrency are supported" in
1354 perlguts for additional information about PERL_NO_GET_CONTEXT.
1355 Implementation header dbdimp.h
1357 This header file has two jobs:
1359 First it defines data structures for your private part of the handles.
1361 Second it defines macros that rename the generic names like
1363 dbd_db_login to database specific names like ora_db_login. This avoids
1364 name clashes and enables use of different drivers when you work with a
1365 statically linked perl.
1366 It also will have the important task of disabling XS methods that you
1368 don't want to implement.
1369 Finally, the macros will also be used to select alternate implementa‐
1371 tions of some functions. For example, the dbd_db_login function is not
1372 passed the attribute hash. Since DBI v1.06, if a dbd_db_login6 macro
1373 is defined (for a function with 6 arguments), it will be used instead
1374 with the attribute hash passed as the sixth argument.
1375 People used to just pick Oracle's dbdimp.c and use the same names,
1377 structures and types. I strongly recommend against that. At first
1378 glance this saves time, but your implementation will be less readable.
1379 It was just hell when I had to separate DBI specific parts, Oracle spe‐
1380 cific parts, mSQL specific parts and mysql specific parts in
1381 DBD::mysql's dbdimp.h and dbdimp.c. (DBD::mysql was a port of
1382 DBD::mSQL which was based on DBD::Oracle.) [Seconded, based on the
1383 experience taking DBD::Informix apart, even though the version inher‐
1384 ited in 1996 was only based on DBD::Oracle.]
1385 This part of the driver is your exclusive part. Rewrite it from
1387 scratch, so it will be clean and short: in other words, a better piece
1388 of code. (Of course keep an eye on other people's work.)
1389 struct imp_drh_st {
1391 dbih_drc_t com; /* MUST be first element in structure */
1392 /* Insert your driver handle attributes here */
1393 };
1394 struct imp_dbh_st {
1396 dbih_dbc_t com; /* MUST be first element in structure */
1397 /* Insert your database handle attributes here */
1398 };
1399 struct imp_sth_st {
1401 dbih_stc_t com; /* MUST be first element in structure */
1402 /* Insert your statement handle attributes here */
1403 };
1404 /* Rename functions for avoiding name clashes; prototypes are */
1406 /* in dbd_xst.h */
1407 #define dbd_init drv_dr_init
1408 #define dbd_db_login6 drv_db_login
1409 #define dbd_db_do drv_db_do
1410 ... many more here ...
1411 These structures implement your private part of the handles. You have
1413 to use the name imp_dbh_{dr⎪db⎪st} and the first field must be of type
1414 dbih_drc_t⎪_dbc_t⎪_stc_t and must be called "com". You should never
1415 access these fields directly, except by using the DBIc_xxx macros
1416 below.
1417 Implementation source dbdimp.c
1419 Conventionally, dbdimp.c is the main implementation file (but
1421 DBD::Informix calls the file dbdimp.ec). This section includes a short
1422 note on each function that is used in the Driver.xsi template and thus
1423 has to be implemented.
1424 Of course, you will probably also need to implement other support func‐
1426 tions, which should usually be file static if the are placed in
1427 dbdimp.c. If they are placed in other files, you need to list those
1428 files in Makefile.PL (and MANIFEST) to handle them correctly.
1429 It is wise to adhere to a namespace convention for your functions to
1431 avoid conflicts. For example, for a driver with prefix "drv", you
1432 might call externally visible functions "dbd_drv_xxxx". You should
1433 also avoid non-constant global variables as much as possible to improve
1434 the support for threading.
1435 Since Perl requires support for function prototypes (ANSI or ISO or
1437 Standard C), you should write your code using function prototypes too.
1438 It is possible to use either the unmapped names such as "dbd_init" or
1440 the mapped names such as "dbd_ix_dr_init" in the "dbdimp.c" file.
1441 DBD::Informix uses the mapped names which makes it easier to identify
1442 where to look for linkage problems at runtime (which will report errors
1443 using the mapped names). Most other drivers, and in particular
1444 DBD::Oracle, use the unmapped names in the source code which makes it a
1445 little easier to compare code between drivers and eases discussions on
1446 the dbi-dev mailing list. The majority of the code fragments here will
1447 use the unmapped names.
1448 Ultimately, you should provide implementations for most fo the func‐
1450 tions listed in the dbd_xsh.h header. The exceptions are optional
1451 functions (such as dbd_st_rows) and those functions with alternative
1452 signatures, such as dbd_db_login6 and dbd_db_login. Then you should
1453 only implement one of the alternatives, and generally the newer one of
1454 the alternatives.
1455 The dbd_init method
1457 #include "Driver.h"
1459 DBISTATE_DECLARE;
1461 void dbd_init(dbistate_t* dbistate)
1463 {
1464 DBISTATE_INIT; /* Initialize the DBI macros */
1465 }
1466 The "dbd_init" function will be called when your driver is first
1468 loaded; the bootstrap command in DBD::Driver::dr::driver triggers this,
1469 and the call is generated in the BOOT section of Driver.xst. These
1470 statements are needed to allow your driver to use the DBI macros. They
1471 will include your private header file dbdimp.h in turn. Note that
1472 DBISTATE_INIT requires the name of the argument to dbd_init to be
1473 called dbistate.
1474 The dbd_drv_error method
1476 You need a function to record errors so DBI can access them properly.
1478 You can call it whatever you like, but we'll call it "dbd_drv_error"
1479 here. The argument list depends on your database software; different
1480 systems provide different ways to get at error information.
1481 static void dbd_drv_error(SV *h, int rc, const char *what)
1483 {
1484 Note that h is a generic handle, may it be a driver handle, a database
1486 or a statement handle.
1487 D_imp_xxh(h);
1489 This macro will declare and initialize a variable imp_xxh with a
1491 pointer to your private handle pointer. You may cast this to to
1492 imp_drh_t, imp_dbh_t or imp_sth_t.
1493 To record the error correctly, equivalent to the set_err() method, use
1495 one of the DBIh_SET_ERR_CHAR(...) or DBIh_SET_ERR_SV(...) macros, which
1496 were added in DBI 1.41:
1497 DBIh_SET_ERR_SV(h, imp_xxh, err, errstr, state, method);
1499 DBIh_SET_ERR_CHAR(h, imp_xxh, err_c, err_i, errstr, state, method);
1500 For DBIh_SET_ERR_SV the err, errstr, state, and method parameters are
1502 SV*. For DBIh_SET_ERR_CHAR the err_c, errstr, state, method are char*.
1503 The err_i parameter is an IV that's used instead of err_c is err_c is
1504 Null. The method parameter can be ignored.
1505 The DBIh_SET_ERR_CHAR macro is usually the simplest to use when you
1507 just have an integer error code and an error message string:
1508 DBIh_SET_ERR_CHAR(h, imp_xxh, Nullch, rc, what, Nullch, Nullch);
1510 As you can see, any parameters that aren't relevant to you can be Null.
1512 To make drivers compatible with DBI < 1.41 you should be using dbiv‐
1514 port.h as described in "Driver.h" above.
1515 The (obsolete) macros such as DBIh_EVENT2 should be removed from driv‐
1517 ers.
1518 The names dbis and DBIS, which were used in previous versions of this
1520 document, should be replaced with the "DBIc_STATE(imp_xxh)" macro.
1521 The name DBILOGFP, which was also used in previous versions of this
1523 document, should be replaced by DBIc_LOGPIO(imp_xxh).
1524 Your code should not call the C "<stdio.h>" I/O functions; you should
1526 use "PerlIO_printf"() as shown:
1527 if (DBIc_TRACE_LEVEL(imp_xxh) >= 2)
1529 PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar %s: %s\n",
1530 foo, neatsvpv(errstr,0));
1531 That's the first time we see how tracing works within a DBI driver.
1533 Make use of this as often as you can! But don't output anything at a
1534 trace level less than 3. Levels 1 and 2 are reserved for the DBI.
1535 You can define up to 8 private trace flags using the top 8 bits of
1537 DBIc_TRACE_FLAGS(imp), that is: 0xFF000000. See the parse_trace_flag()
1538 method elsewhere in this document.
1539 The dbd_dr_data_sources method
1541 This method is optional; the support for it was added in DBI v1.33.
1543 As noted in the discussion of Driver.pm, if the data sources can be
1545 determined by pure Perl code, do it that way. If, as in DBD::Informix,
1546 the information is obtained by a C function call, then you need to
1547 define a function that matches the prototype:
1548 extern AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attrs);
1550 An outline implementation for DBD::Informix follows, assuming that the
1552 sqgetdbs() function call shown will return up to 100 databases names,
1553 with the pointers to each name in the array dbsname and the name
1554 strings themselves being stores in dbsarea. The actual DBD::Informix
1555 implementation has a number of extra lines of code, logs function entry
1556 and exit, reports the error from sqgetdbs(), and uses #define'd con‐
1557 statnts for the array sizes.
1558 AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attr)
1560 {
1561 int ndbs;
1562 int i;
1563 char *dbsname[100];
1564 char dbsarea[10000];
1565 AV *av = Nullav;
1566 if (sqgetdbs(&ndbs, dbsname, 100, dbsarea, sizeof(dbsarea)) == 0)
1568 {
1569 av = NewAV();
1570 av_extend(av, (I32)ndbs);
1571 sv_2mortal((SV *)av);
1572 for (i = 0; i < ndbs; i++)
1573 av_store(av, i, newSVpvf("dbi:Informix:%s", dbsname[i]));
1574 }
1575 return(av);
1576 }
1577 The dbd_db_login6 method
1579 int dbd_db_login6(SV* dbh, imp_dbh_t* imp_dbh, char* dbname,
1581 char* user, char* auth, SV *attr);
1582 This function will really connect to the database. The argument dbh is
1584 the database handle. imp_dbh is the pointer to the handles private
1585 data, as is imp_xxx in dbd_drv_error above. The arguments dbname,
1586 user, auth and attr correspond to the arguments of the driver handle's
1587 connect method.
1588 You will quite often use database specific attributes here, that are
1590 specified in the DSN. I recommend you parse the DSN (using Perl)
1591 within the connect method and pass the segments of the DSN via the
1592 attributes parameter through _login to dbd_db_login6. Here's how you
1593 fetch them; as an example we use hostname attribute, which can be up to
1594 12 characters long excluding null terminator:
1595 SV** svp;
1597 STRLEN len;
1598 char* hostname;
1599 if ( (svp = DBD_ATTRIB_GET_SVP(attr, "drv_hostname", 12)) && SvTRUE(*svp)) {
1601 hostname = SvPV(*svp, len);
1602 DBD__ATTRIB_DELETE(attr, "drv_hostname", 12); /* avoid later STORE */
1603 } else {
1604 hostname = "localhost";
1605 }
1606 Note that you can also obtain standard attributes such as AutoCommit
1608 and ChopBlanks from the attributes parameter, using DBD_ATTRIB_GET_IV
1609 for integer attributes. If, for example, your database does not sup‐
1610 port transactions but AutoCommit is set off (requesting transaction
1611 support), then you can emulate a 'failure to connect'.
1612 Now you should really connect to the database. In general, if the con‐
1614 nection fails, it is best to ensure that all allocated resources are
1615 released so that the handle does not need to be destroyed separately.
1616 If you are successful (and possibly even if you fail but you have allo‐
1617 cated some resources), you should use the following macros:
1618 DBIc_IMPSET_on(imp_dbh);
1620 This indicates that the driver (implementor) has allocated resources in
1622 the imp_dbh structure and that the implementors private dbd_db_destroy
1623 function should be called when the handle is destroyed.
1624 DBIc_ACTIVE_on(imp_dbh);
1626 This indicates that the handle has an active connection to the server
1628 and that the dbd_db_disconnect function should be called before the
1629 handle is destroyed.
1630 Note that if you do need to fail, you should report errors via the drh
1632 or imp_drh rather than via dbh or imp_dbh because imp_dbh will be
1633 destroyed by the failure, so errors recorded in that handle will not be
1634 visible to DBI, and hence not the user either. Note to that the func‐
1635 tion is passed dbh and imp_dbh, and there is a macro D_imp_drh_from_dbh
1636 which can recover the imp_drh from the imp_dbh, but there is no DBI
1637 macro to provide you with the drh given either the imp_dbh or the dbh
1638 or the imp_drh (and there's no way to recover the dbh given just the
1639 imp_dbh). This suggests that despite the notes about dbd_drv_error
1640 above taking an SV *, it may be better to have two error routines, one
1641 taking imp_dbh and one taking imp_drh instead. With care, you can fac‐
1642 tor most of the formatting code out so that these are small routines
1643 calling onto a common error formatter. See the code in DBD::Informix
1644 1.05.00 for more information.
1645 The dbd_db_login6 function should return TRUE for success, FALSE other‐
1647 wise.
1648 Drivers implemented long ago may define the five-argument function
1650 dbd_db_login instead of dbd_db_login6. The missing argument is the
1651 attributes. There are ways to work around the missing attributes, but
1652 they are ungainly; it is much better to use the 6-argument form.
1653 The dbd_db_commit and dbd_db_rollback methods
1655 int dbd_db_commit(SV *dbh, imp_dbh_t *imp_dbh);
1657 int dbd_db_rollback(SV* dbh, imp_dbh_t* imp_dbh);
1658 These are used for commit and rollback. They should return TRUE for
1660 success, FALSE for error.
1661 The arguments dbh and imp_dbh are the same as for dbd_db_login6 above;
1663 I will omit describing them in what follows, as they appear always.
1664 These functions should return TRUE for success, FALSE otherwise.
1666 The dbd_db_disconnect method
1668 This is your private part of the disconnect method. Any dbh with the
1670 ACTIVE flag on must be disconnected. (Note that you have to set it in
1671 dbd_db_connect above.)
1672 int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);
1674 The database handle will return TRUE for success, FALSE otherwise. In
1676 any case it should do a:
1677 DBIc_ACTIVE_off(imp_dbh);
1679 before returning so DBI knows that dbd_db_disconnect was executed.
1681 Note that there's nothing to stop a dbh being disconnected while it
1683 still have active children. If your database API reacts badly to try‐
1684 ing to use an sth in this situation then you'll need to add code like
1685 this to all sth methods:
1686 if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth)))
1688 return 0;
1689 Alternatively, you can add code to your driver to keep explicit track
1691 of the statement handles that exist for each database handle and
1692 arrange to destroy those handles before disconnecting from the data‐
1693 base. There is code to do this in DBD::Informix. Similar comments
1694 apply to the driver handle keeping track of all the database handles.
1695 Note that the code which destroys the subordinate handles should only
1696 release the associated database resources and mark the handles inac‐
1697 tive; it does not attempt to free the actual handle structures.
1698 This function should return TRUE for success, FALSE otherwise, but it
1700 is not clear what anything can do about a failure.
1701 The dbd_db_discon_all method
1703 int dbd_discon_all (SV *drh, imp_drh_t *imp_drh);
1705 This function may be called at shutdown time. It should make best-
1707 efforts to disconnect all database handles - if possible. Some data‐
1708 bases don't support that, in which case you can do nothing but return
1709 'success'.
1710 This function should return TRUE for success, FALSE otherwise, but it
1712 is not clear what anything can do about a failure.
1713 The dbd_db_destroy method
1715 This is your private part of the database handle destructor. Any dbh
1717 with the IMPSET flag on must be destroyed, so that you can safely free
1718 resources. (Note that you have to set it in dbd_db_connect above.)
1719 void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh)
1721 {
1722 DBIc_IMPSET_off(imp_dbh);
1723 }
1724 The DBI Driver.xst code will have called dbd_db_disconnect for you, if
1726 the handle is still 'active', before calling dbd_db_destroy.
1727 Before returning the function must switch IMPSET to off, so DBI knows
1729 that the destructor was called.
1730 A DBI handle doesn't keep references to its children. But children do
1732 keep references to their parents. So a database handle won't be
1733 DESTROY'd until all its children have been DESTROY'd.
1734 The dbd_db_STORE_attrib method
1736 This function handles
1738 $dbh->{$key} = $value;
1740 Its prototype is:
1742 int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
1744 SV* valuesv);
1745 You do not handle all attributes; on the contrary, you should not han‐
1747 dle DBI attributes here: leave this to DBI. (There are two exceptions,
1748 AutoCommit and ChopBlanks, which you should care about.)
1749 The return value is TRUE if you have handled the attribute or FALSE
1751 otherwise. If you are handling an attribute and something fails, you
1752 should call dbd_drv_error, so DBI can raise exceptions, if desired. If
1753 dbd_drv_error returns, however, you have a problem: the user will never
1754 know about the error, because he typically will not check
1755 "$dbh->errstr".
1756 I cannot recommend a general way of going on, if dbd_drv_error returns,
1758 but there are examples where even the DBI specification expects that
1759 you croak(). (See the AutoCommit method in DBI.)
1760 If you have to store attributes, you should either use your private
1762 data structure imp_xxx, the handle hash (via (HV*)SvRV(dbh)), or use
1763 the private imp_data.
1764 The first is best for internal C values like integers or pointers and
1766 where speed is important within the driver. The handle hash is best for
1767 values the user may want to get/set via driver-specific attributes.
1768 The private imp_data is an additional SV attached to the handle. You
1769 could think of it as an unnamed handle attribute. It's not normally
1770 used.
1771 The dbd_db_FETCH_attrib method
1773 This is the counterpart of dbd_db_STORE_attrib, needed for:
1775 $value = $dbh->{$key};
1777 Its prototype is:
1779 SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv);
1781 Unlike all previous methods this returns an SV with the value. Note
1783 that you should normally execute sv_2mortal, if you return a noncon‐
1784 stant value. (Constant values are &sv_undef, &sv_no and &sv_yes.)
1785 Note, that DBI implements a caching algorithm for attribute values. If
1787 you think, that an attribute may be fetched, you store it in the dbh
1788 itself:
1789 if (cacheit) /* cache value for later DBI 'quick' fetch? */
1791 hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);
1792 The dbd_st_prepare method
1794 This is the private part of the prepare method. Note that you must not
1796 really execute the statement here. You may, for example, preparse and
1797 validate the statement or do similar things.
1798 int dbd_st_prepare(SV* sth, imp_sth_t* imp_sth, char* statement,
1800 SV* attribs);
1801 A typical, simple, possibility is to do nothing and rely on the perl
1803 perpare() code that set the Statement attribute on the handle. This
1804 attribute can then be used by dbd_st_execute.
1805 If the driver supports placeholders then the NUM_OF_PARAMS attribute
1807 must be set correctly by dbd_st_prepare:
1808 DBIc_NUM_PARAMS(imp_sth) = ...
1810 If you can, you should also setup attributes like NUM_OF_FIELDS, NAME,
1812 ... here, but DBI doesn't require that. However, if you do, document
1813 it.
1814 In any case you should set the IMPSET flag, as you did in dbd_db_con‐
1816 nect above:
1817 DBIc_IMPSET_on(imp_sth);
1819 The dbd_st_execute method
1821 This is where a statement will really be executed.
1823 int dbd_st_execute(SV* sth, imp_sth_t* imp_sth);
1825 Note, that you must be aware, that a statement may be executed repeat‐
1827 edly. Also, you should not expect, that finish will be called between
1828 two executions, so you'll might need code like the following near the
1829 start of the function:
1830 if (DBIc_ACTIVE(imp_sth))
1832 dbd_st_finish(h, imp_sth);
1833 If your driver supports the binding of parameters (it should!), but the
1835 database doesn't, you must do it here. This can be done as follows:
1836 SV *svp;
1838 char* statement = DBD_ATTRIB_GET_PV(h, "Statement", 9, svp, "");
1839 int numParam = DBIc_NUM_PARAMS(imp_sth);
1840 int i;
1841 for (i = 0; i < numParam; i++)
1843 {
1844 char* value = dbd_db_get_param(sth, imp_sth, i);
1845 /* It is your drivers task to implement dbd_db_get_param, */
1846 /* it must be setup as a counterpart of dbd_bind_ph. */
1847 /* Look for '?' and replace it with 'value'. Difficult */
1848 /* task, note that you may have question marks inside */
1849 /* quotes and comments the like ... :-( */
1850 /* See DBD::mysql for an example. (Don't look too deep into */
1851 /* the example, you will notice where I was lazy ...) */
1852 }
1853 The next thing is you really execute the statement. Note that you must
1855 set the attributes NUM_OF_FIELDS, NAME, etc when the statement is suc‐
1856 cessfully executed if the driver has not already done so. They may be
1857 used even before a potential fetchrow. In particular you have to tell
1858 DBI the number of fields, that the statement has, because it will be
1859 used by DBI internally. Thus the function will typically ends with:
1860 if (isSelectStatement) {
1862 DBIc_NUM_FIELDS(imp_sth) = numFields;
1863 DBIc_ACTIVE_on(imp_sth);
1864 }
1865 It is important that the ACTIVE flag only be set for "SELECT" state‐
1867 ments (or any other statements that can return multiple sets of values
1868 from the database using a cursor-like mechanism). See dbd_db_connect
1869 above for more explanations.
1870 There plans for a preparse function to be provided by DBI, but this has
1872 not reached fruition yet. Meantime, if you want to know how ugly it
1873 can get, try looking at the dbd_ix_preparse in DBD::Informix dbdimp.ec
1874 and the related functions in iustoken.c and sqltoken.c.
1875 The dbd_st_fetch method
1877 This function fetches a row of data. The row is stored in in an array,
1879 of SV's that DBI prepares for you. This has two advantages: it is fast
1880 (you even reuse the SV's, so they don't have to be created after the
1881 first fetchrow), and it guarantees that DBI handles bind_cols for you.
1882 What you do is the following:
1884 AV* av;
1886 int numFields = DBIc_NUM_FIELDS(imp_sth); /* Correct, if NUM_FIELDS
1887 is constant for this statement. There are drivers where this is
1888 not the case! */
1889 int chopBlanks = DBIc_is(imp_sth, DBIcf_ChopBlanks);
1890 int i;
1891 if (!fetch_new_row_of_data(...)) {
1893 ... /* check for error or end-of-data */
1894 DBIc_ACTIVE_off(imp_sth); /* turn off Active flag automatically */
1895 return Nullav;
1896 }
1897 /* get the fbav (field buffer array value) for this row */
1898 /* it is very important to only call this after you know */
1899 /* that you have a row of data to return. */
1900 av = DBIc_DBISTATE(imp_sth)->get_fbav(imp_sth);
1901 for (i = 0; i < numFields; i++) {
1902 SV* sv = fetch_a_field(..., i);
1903 if (chopBlanks && SvOK(sv) && type_is_blank_padded(field_type[i])) {
1904 /* Remove white space from end (only) of sv */
1905 }
1906 sv_setsv(AvARRAY(av)[i], sv); /* Note: (re)use! */
1907 }
1908 return av;
1909 There's no need to use a fetch_a_field function returning an SV*. It's
1911 more common to use your database API functions to fetch the data as
1912 character strings and use code like this:
1913 sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);
1915 NULL values must be returned as undef. You can use code like this:
1917 SvOK_off(AvARRAY(av)[i]);
1919 The function returns the AV prepared by DBI for success or "Nullav"
1921 otherwise.
1922 *FIX ME* Discuss what happens when there's no more data to fetch.
1924 Are errors permitted if another fetch occurs after the first fetch
1925 that reports no more data. (Permitted, not required.)
1926 If an error occurs which leaves the $sth in a state where remaining
1928 rows can't be fetched then Active should be turned off before the
1929 method returns.
1930 The dbd_st_finish3 method
1932 The "$sth->finish" method can be called if the user wishes to indicate
1934 that no more rows will be fetched even if the database has more rows to
1935 offer, and the DBI code can call the function when handles are being
1936 destroyed. See the DBI specification for more background details. In
1937 both circumstances, the DBI code ends up calling the "dbd_st_finish3"
1938 method (if you provide a mapping for dbd_st_finish3 in dbdimp.h), or
1939 dbd_st_finish otherwise. The difference is that dbd_st_finish3 takes a
1940 third argument which is an "int" with the value 1 if it is being called
1941 from a destroy method and 0 otherwise.
1942 Note that DBI v1.32 and earlier test on dbd_db_finish3 to call
1944 dbd_st_finish3; if you provide dbd_st_finish3, either define
1945 dbd_db_finish3 too, or insist on DBI v1.33 or later.
1946 All it needs to do is turn off the Active flag for the sth. It will
1948 only be called by Driver.xst code, if the driver has set ACTIVE to on
1949 for the sth.
1950 Outline example:
1952 int dbd_st_finish3(SV* sth, imp_sth_t* imp_sth, int from_destroy) {
1954 if (DBIc_ACTIVE(imp_sth))
1955 {
1956 /* close cursor or equivalent action */
1957 DBIc_ACTIVE_off(imp_sth);
1958 }
1959 return 1;
1960 }
1961 The from_destroy parameter is true if dbd_st_finish3 is being called
1963 from DESTROY - and so the statement is about to be destroyed. For many
1964 drivers there's no point in doing anything more than turing of the
1965 Active flag in this case.
1966 The function returns TRUE for success, FALSE otherwise, but there isn't
1968 a lot anyone can do to recover if there is an error.
1969 The dbd_st_destroy method
1971 This function is the private part of the statement handle destructor.
1973 void dbd_st_destroy(SV* sth, imp_sth_t* imp_sth) {
1975 ... /* any clean-up that's needed */
1976 DBIc_IMPSET_off(imp_sth); /* let DBI know we've done it */
1977 }
1978 The DBI Driver.xst code will call dbd_st_finish for you, if the sth has
1980 the ACTIVE flag set, before calling dbd_st_destroy.
1981 The dbd_st_STORE_attrib and dbd_st_FETCH_attrib methods
1983 These functions correspond to dbd_db_STORE and dbd_db_FETCH attrib
1985 above, except that they are for statement handles. See above.
1986 int dbd_st_STORE_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv,
1988 SV* valuesv);
1989 SV* dbd_st_FETCH_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv);
1990 The dbd_bind_ph method
1992 This function is internally used by the bind_param method, the
1994 bind_param_inout method and by the DBI Driver.xst code if "execute" is
1995 called with any bind parameters.
1996 int dbd_bind_ph (SV *sth, imp_sth_t *imp_sth, SV *param,
1998 SV *value, IV sql_type, SV *attribs,
1999 int is_inout, IV maxlen);
2000 The param argument holds an IV with the parameter number (1, 2, ...).
2002 The value argument is the parameter value and sql_type is its type.
2003 If your driver does not support bind_param_inout then you should ignore
2005 maxlen and croak if is_inout is TRUE.
2006 If your driver does support bind_param_inout then you should note that
2008 value is the SV after dereferencing the reference passed to
2009 bind_param_inout.
2010 In drivers of simple databases the function will, for example, store
2012 the value in a parameter array and use it later in dbd_st_execute. See
2013 the DBD::mysql driver for an example.
2014 Implementing bind_param_inout support
2016 To provide support for parameters bound by reference rather than by
2018 value, the driver must do a number of things. First, and most impor‐
2019 tantly, it must note the references and stash them in its own driver
2020 structure. Secondly, when a value is bound to a column, the driver
2021 must discard any previous reference bound to the column. On each exe‐
2022 cute, the driver must evaluate the references and internally bind the
2023 values resulting from the references. This is only applicable if the
2024 user writes:
2025 $sth->execute;
2027 If the user writes:
2029 $sth->execute(@values);
2031 then DBI automatically calls the binding code for each element of @val‐
2033 ues. These calls are indistinguishable from explicit user calls to
2034 bind_param.
2035 C/XS version of Makefile.PL
2037 The Makefile.PL file for a C/XS driver is similar to the code needed
2039 for a pure Perl driver, but there are a number of extra bits of infor‐
2040 mation needed by the build system. For example, the attributes list
2041 passed to "WriteMakefile" needs to specify the object files that need
2042 to be compiled and built into the shared object (DLL). This is often,
2043 but not necessarily, just dbdimp.o (unless that should be dbdimp.obj
2044 because you're building on MS Windows). Note that you can reliably
2045 determine the extension of the object files from the $Config{obj_ext}
2046 values, and there are many other useful pieces of configuration infor‐
2047 mation lurking in that hash. You get access to it with:
2048 use Config;
2050 Methods which do not need to be written
2052 The DBI code implements the majority of the methods which are accessed
2054 using the notation DBI->function(), the only exceptions being DBI->con‐
2055 nect() and DBI->data_sources() which require support from the driver.
2056 The DBI code implements the following documented driver, database and
2058 statement functions which do not need to be written by the DBD driver
2059 writer.
2060 $dbh->do()
2062 The default implementation of this function prepares, executes and
2063 destroys the statement. This can be replaced if there is a better
2064 way to implement this, such as EXECUTE IMMEDIATE which can some‐
2065 times be used if there are no parameters.
2066 $h->errstr()
2068 $h->err()
2069 $h->state()
2070 $h->trace()
2071 The DBD driver does not need to worry about these routines at all.
2072 $h->{ChopBlanks}
2074 This attribute needs to be honured during fetch operations, but
2075 does not need to be handled by the attribute handling code.
2076 $h->{RaiseError}
2078 The DBD driver does not need to worry about this attribute at all.
2079 $h->{PrintError}
2081 The DBD driver does not need to worry about this attribute at all.
2082 $sth->bind_col()
2084 Assuming the driver uses the DBIc_DBISTATE(imp_xxh)->get_fbav()
2085 function (C drivers, see below), or the $sth->_set_fbav($data)
2086 method (Perl drivers) the driver does not need to do anything about
2087 this routine.
2088 $sth->bind_columns()
2090 Regardless of whether the driver uses DBIc_DBIS‐
2091 TATE(imp_xxh)->get_fbav(), the driver does not need to do anything
2092 about this routine as it simply iteratively calls $sth->bind_col().
2093 The DBI code implements a default implementation of the following func‐
2095 tions which do not need to be written by the DBD driver writer unless
2096 the default implementation is incorrect for the Driver.
2097 $dbh->quote()
2099 This should only be written if the database does not accept the
2100 ANSI SQL standard for quoting strings, with the string enclosed in
2101 single quotes and any embedded single quotes replaced by two con‐
2102 secutive single quotes.
2103 For the two argument form of quote, you need to implement the
2105 "type_info" method to provide the information that quote needs.
2106 $dbh->ping()
2108 This should be implemented as a simple efficient way to determine
2109 whether the connection to the database is still alive. Typically
2110 code like this:
2111 sub ping {
2113 my $dbh = shift;
2114 $sth = $dbh->prepare_cached(q{
2115 select * from A_TABLE_NAME where 1=0
2116 }) or return 0;
2117 $sth->execute or return 0;
2118 $sth->finish;
2119 return 1;
2120 }
2121 where A_TABLE_NAME is the name of a table that always exists (such
2123 as a database system catalogue).
2124
2126 The exposition above ignores the DBI MetaData methods. The metadata
2127 methods are all associated with a database handle.
2128 Using DBI::DBD::Metadata
2130 The DBI::DBD::Metadata module is a good semi-automatic way for the
2132 developer of a DBD module to write the get_info and type_info functions
2133 quickly and accurately.
2134 Generating the get_info method
2136 Prior to DBI v1.33, this existed as the method write_getinfo_pm in the
2138 DBI::DBD module. From DBI v1.33, it exists as the method write_get‐
2139 info_pm in the DBI::DBD::Metadata module. This discussion assumes you
2140 have DBI v1.33 or later.
2141 You examine the documentation for write_getinfo_pm using:
2143 perldoc DBI::DBD::Metadata
2145 To use it, you need a Perl DBI driver for your database which imple‐
2147 ments the get_info method. In practice, this means you need to install
2148 DBD::ODBC, an ODBC driver manager, and an ODBC driver for your data‐
2149 base. With the pre-requisites in place, you might type:
2150 perl -MDBI::DBD::Metadata -e write_getinfo_pm \
2152 dbi:ODBC:foo_db username password Driver
2153 The procedure writes to standard output the code that should be added
2155 to your Driver.pm file and the code that should be written to
2156 lib/DBD/Driver/GetInfo.pm. You should review the output to ensure that
2157 it is sensible.
2158 Generating the type_info method
2160 Given the idea of the write_getinfo_pm method, it was not hard to
2162 devise a parallel method, write_typeinfo_pm, which does the analogous
2163 job for the DBI type_info_all metadata method. The the write_type‐
2164 info_pm method was added to DBI v1.33.
2165 You examine the documentation for write_typeinfo_pm using:
2167 perldoc DBI::DBD::Metadata
2169 The setup is exactly analogous to the mechanism descibed in "Generating
2171 the get_info method" With the pre-requisites in place, you might type:
2172 perl -MDBI::DBD::Metadata -e write_typeinfo \
2174 dbi:ODBC:foo_db username password Driver
2175 The procedure writes to standard output the code that should be added
2177 to your Driver.pm file and the code that should be written to
2178 lib/DBD/Driver/TypeInfo.pm. You should review the output to ensure
2179 that it is sensible.
2180 Writing DBD::Driver::db::get_info
2182 If you use the DBI::DBD::Metadata module, then the code you need is
2184 generated for you.
2185 If you decide not to use the DBI::DBD::Metadata module, you should
2187 probably borrow the code from a driver that has done so (eg
2188 DBD::Informix from version 1.05 onwards) and crib the code from there,
2189 or look at the code that generates that module and follow that. The
2190 method in Driver.pm will be very simple; the method in
2191 lib/DBD/Driver/GetInfo.pm is not very much more complex unless your
2192 DBMS itself is much more complex.
2193 Note that some of the DBI utility methods rely on information from the
2195 get_info method to perform their operations correctly. See, for exam‐
2196 ple, the quote_identifier and quote methods, discussed below.
2197 Writing DBD::Driver::db::type_info_all
2199 If you use the DBI::DBD::Metadata module, then the code you need is
2201 generated for you.
2202 If you decide not to use the DBI::DBD::Metadata module, you should
2204 probably borrow the code from a driver that has done so (eg
2205 DBD::Informix from version 1.05 onwards) and crib the code from there,
2206 or look at the code that generates that module and follow that. The
2207 method in Driver.pm will be very simple; the method in
2208 lib/DBD/Driver/TypeInfo.pm is not very much more complex unless your
2209 DBMS itself is much more complex.
2210 Writing DBD::Driver::db::type_info
2212 The guidelines on writing this method are still not really clear. No
2214 sample implementation is available.
2215 Writing DBD::Driver::db::table_info
2217 *FIX ME* The guidelines on writing this method have not been written yet.
2219 No sample implementation is available.
2220 Writing DBD::Driver::db::column_info
2222 *FIX ME* The guidelines on writing this method have not been written yet.
2224 No sample implementation is available.
2225 Writing DBD::Driver::db::primary_key_info
2227 *FIX ME* The guidelines on writing this method have not been written yet.
2229 No sample implementation is available.
2230 Writing DBD::Driver::db::primary_key
2232 *FIX ME* The guidelines on writing this method have not been written yet.
2234 No sample implementation is available.
2235 Writing DBD::Driver::db::foreign_key_info
2237 *FIX ME* The guidelines on writing this method have not been written yet.
2239 No sample implementation is available.
2240 Writing DBD::Driver::db::tables
2242 This method generates an array of names in a format suitable for being
2244 embedded in SQL statements in places where a table name is expected.
2245 If your database hews close enough to the SQL standard or if you have
2247 implemented an appropriate table_info function and and the appropriate
2248 quote_identifier function, then the DBI default version of this method
2249 will work for your driver too.
2250 Otherwise, you have to write a function yourself, such as:
2252 sub tables
2254 {
2255 my($dbh, $cat, $sch, $tab, $typ) = @_;
2256 my(@res);
2257 my($sth) = $dbh->table_info($cat, $sch, $tab, $typ);
2258 my(@arr);
2259 while (@arr = $sth->fetchrow_array)
2260 {
2261 push @res, $dbh->quote_identifier($arr[0], $arr[1], $arr[2]);
2262 }
2263 return @res;
2264 }
2265 See also the default implementation in DBI.pm.
2267 Writing DBD::Driver::db::quote
2269 This method takes a value and converts it into a string suitable for
2271 embedding in an SQL statement as a string literal.
2272 If your DBMS accepts the SQL standard notation for strings (single
2274 quotes around the string as a whole with any embedded single quotes
2275 doubled up), then you do not need to write this method as DBI provides
2276 a default method that does it for you. If your DBMS uses an alterna‐
2277 tive notation or escape mechanism, then you need to provide an equiva‐
2278 lent function. For example, suppose your DBMS used C notation with
2279 double quotes around the string and backslashes escaping both double
2280 quotes and backslashes themselves. Then you might write the function
2281 as:
2282 sub quote
2284 {
2285 my($dbh, $str) = @_;
2286 $str =~ s/["\\]/\\$&/gmo;
2287 return qq{"$str"};
2288 }
2289 Handling newlines and other control characters is left as an exercise
2291 for the reader.
2292 This sample method ignores the $data_type indicator which is the
2294 optional second argument to the method.
2295 Writing DBD::Driver::db::quote_identifier
2297 This method is called to ensure that the name of the given table (or
2299 other database object) can be embedded into an SQL statement without
2300 danger of misinterpretation. The result string should be usable in the
2301 text of an SQL statement as the identifier for a table.
2302 If your DBMS accepts the SQL standard notation for quoted identifiers
2304 (which uses double quotes around the identifier as a whole, with any
2305 embedded double quotes doubled up) and accepts "schema"."identifier"
2306 (and "catalog"."schema"."identifier" when a catalog is specified), then
2307 you do not need to write this method as DBI provides a default method
2308 that does it for you. In fact, even if your DBMS does not handle
2309 exactly that notation but you have implemented the get_info method and
2310 it gives the correct responses, then it will work for you. If your
2311 database is fussier, then you need to implement your own version of the
2312 function.
2313 For example, DBD::Informix has to deal with an environment variable
2315 DELIMIDENT. If it is not set, then the DBMS treats names enclosed in
2316 double quotes as strings rather than names, which is usually a syntax
2317 error. Additionally, the catalog portion of the name is separated from
2318 the schema and table by a different delimiter (colon instead of dot),
2319 and the catalog portion is never enclosed in quotes. (Fortunately,
2320 valid strings for the catalog will never contain weird characters that
2321 might need to be escaped, unless you count dots, dashes, slashes and
2322 at-signs as weird.) Finally, an Informix database can contain objects
2323 that cannot be accessed because they were created by a user with the
2324 DELIMIDENT environment variable set, but the current user does not have
2325 it set. By design choice, the quote_identifier method encloses those
2326 identifiers in double quotes anyway, which generally triggers a syntax
2327 error, and the metadata methods which generate lists of tables etc omit
2328 those identifiers from the result sets.
2329 sub quote_identifier
2331 {
2332 my($dbh, $cat, $sch, $obj) = @_;
2333 my($rv) = "";
2334 my($qq) = (defined $ENV{DELIMIDENT}) ? '"' : '';
2335 $rv .= qq{$cat:} if (defined $cat);
2336 if (defined $sch)
2337 {
2338 if ($sch !~ m/^\w+$/o)
2339 {
2340 $qq = '"';
2341 $sch =~ s/$qq/$qq$qq/gm;
2342 }
2343 $rv .= qq{$qq$sch$qq.};
2344 }
2345 if (defined $obj)
2346 {
2347 if ($obj !~ m/^\w+$/o)
2348 {
2349 $qq = '"';
2350 $obj =~ s/$qq/$qq$qq/gm;
2351 }
2352 $rv .= qq{$qq$obj$qq};
2353 }
2354 return $rv;
2355 }
2356 Handling newlines and other control characters is left as an exercise
2358 for the reader.
2359 Note that there is an optional fourth parameter to this function which
2361 is a reference to a hash of attributes; this sample implementation
2362 ignores that. This sample implementation also ignores the single-argu‐
2363 ment variant of the method.
2364
2366 Study Oraperl.pm (supplied with DBD::Oracle) and Ingperl.pm (supplied
2367 with DBD::Ingres) and the corresponding dbdimp.c files for ideas.
2368 Note that the emulation code sets $dbh->{CompatMode} = 1; for each con‐
2370 nection so that the internals of the driver can implement behaviour
2371 compatible with the old interface when dealing with those handles.
2372 Setting emulation perl variables
2374 For example, ingperl has a $sql_rowcount variable. Rather than try to
2376 manually update this in Ingperl.pm it can be done faster in C code. In
2377 dbd_init():
2378 sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);
2380 In the relevant places do:
2382 if (DBIc_COMPAT(imp_sth)) /* only do this for compatibility mode handles */
2384 sv_setiv(sql_rowcount, the_row_count);
2385
2387 The imp_xyz_t types
2388 Any handle has a corresponding C structure filled with private data.
2390 Some of this data is reserved for use by DBI (except for using the DBIc
2391 macros below), some is for you. See the description of the dbdimp.h
2392 file above for examples. The most functions in dbdimp.c are passed both
2393 the handle "xyz" and a pointer to "imp_xyz". In rare cases, however,
2394 you may use the following macros:
2395 D_imp_dbh(dbh)
2397 Given a function argument dbh, declare a variable imp_dbh and ini‐
2398 tialize it with a pointer to the handles private data. Note: This
2399 must be a part of the function header, because it declares a vari‐
2400 able.
2401 D_imp_sth(sth)
2403 Likewise for statement handles.
2404 D_imp_xxx(h)
2406 Given any handle, declare a variable imp_xxx and initialize it with a
2407 pointer to the handles private data. It is safe, for example, to cast
2408 imp_xxx to "imp_dbh_t*", if DBIc_TYPE(imp_xxx) == DBIt_DB. (You can
2409 also call sv_derived_from(h, "DBI::db"), but that's much slower.)
2410 D_imp_dbh_from_sth
2412 Given a imp_sth, declare a variable imp_dbh and initialize it with a
2413 pointer to the parent database handle's implementors structure.
2414 Using DBIc_IMPSET_on
2416 The driver code which initializes a handle should use DBIc_IMPSET_on()
2418 as soon as its state is such that the cleanup code must be called.
2419 When this happens is determined by your driver code.
2420 Failure to call this can lead to corruption of data structures. For
2422 example, DBD::Informix maintains a linked list of database handles in
2423 the driver, and within each handle, a linked list of statements. Once
2424 a statement is added to the linked list, it is crucial that it is
2425 cleaned up (removed from the list). When DBIc_IMPSET_on() was being
2426 called too late, it was able to cause all sorts of problems.
2427 Using DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off()
2429 Once upon a long time ago, the only way of handling the internal DBI
2431 boolean flags/attributes was through macros such as:
2432 DBIc_WARN DBIc_WARN_on DBIc_WARN_off
2434 DBIc_COMPAT DBIc_COMPAT_on DBIc_COMPAT_off
2435 Each of these took an imp_xxh pointer as an argument.
2437 Since then, new attributes have been added such as ChopBlanks, RaiseEr‐
2439 ror and PrintError, and these do not have the full set of macros. The
2440 approved method for handling these is now the four macros:
2441 DBIc_is(imp, flag)
2443 DBIc_has(imp, flag) an alias for DBIc_is
2444 DBIc_on(imp, flag)
2445 DBIc_off(imp, flag)
2446 DBIc_set(imp, flag, on) set if on is true, else clear
2447 Consequently, the DBIc_XXXXX family of macros is now mostly deprecated
2449 and new drivers should avoid using them, even though the older drivers
2450 will probably continue to do so for quite a while yet. However...
2451 There is an important exception to that. The ACTIVE and IMPSET flags
2453 should be set via the DBIc_ACTIVE_on and DBIc_IMPSET_on macros, and
2454 unset via the DBIc_ACTIVE_off and DBIc_IMPSET_off macros.
2455 Using the get_fbav() method
2457 THIS IS CRITICAL for C/XS drivers.
2459 The $sth->bind_col() and $sth->bind_columns() documented in the DBI
2461 specification do not have to be implemented by the driver writer
2462 because DBI takes care of the details for you. However, the key to
2463 ensuring that bound columns work is to call the function DBIc_DBIS‐
2464 TATE(imp_xxh)->get_fbav() in the code which fetches a row of data.
2465 This returns an AV, and each element of the AV contains the SV which
2466 should be set to contain the returned data.
2467 The pure Perl equivalent is the $sth->_set_fbav($data) method, as
2469 described in the part on pure Perl drivers.
2470
2472 This is definitely an open subject. It can be done, as demonstrated by
2473 the DBD::File driver, but it is not as simple as one might think.
2474 (Note that this topic is different from subclassing the DBI. For an
2476 example of that, see the t/subclass.t file supplied with the DBI.)
2477 The main problem is that the dbh's and sth's that your connect and pre‐
2479 pare methods return are not instances of your DBD::Driver::db or
2480 DBD::Driver::st packages, they are not even derived from it. Instead
2481 they are instances of the DBI::db or DBI::st classes or a derived sub‐
2482 class. Thus, if you write a method mymethod and do a
2483 $dbh->mymethod()
2485 then the autoloader will search for that method in the package DBI::db.
2487 Of course you can instead to a
2488 $dbh->func('mymethod')
2490 and that will indeed work, even if mymethod is inherited, but not with‐
2492 out additional work. Setting @ISA is not sufficient.
2493 Overwriting methods
2495 The first problem is, that the connect method has no idea of sub‐
2497 classes. For example, you cannot implement base class and subclass in
2498 the same file: The install_driver method wants to do a
2499 require DBD::Driver;
2501 In particular, your subclass has to be a separate driver, from the view
2503 of DBI, and you cannot share driver handles.
2504 Of course that's not much of a problem. You should even be able to
2506 inherit the base classes connect method. But you cannot simply over‐
2507 write the method, unless you do something like this, quoted from
2508 DBD::CSV:
2509 sub connect ($$;$$$) {
2511 my ($drh, $dbname, $user, $auth, $attr) = @_;
2512 my $this = $drh->DBD::File::dr::connect($dbname, $user, $auth, $attr);
2514 if (!exists($this->{csv_tables})) {
2515 $this->{csv_tables} = {};
2516 }
2517 $this;
2519 }
2520 Note that we cannot do a
2522 $drh->SUPER::connect($dbname, $user, $auth, $attr);
2524 as we would usually do in a an OO environment, because $drh is an
2526 instance of DBI::dr. And note, that the connect method of DBD::File is
2527 able to handle subclass attributes. See the description of Pure Perl
2528 drivers above.
2529 It is essential that you always call superclass method in the above
2531 manner. However, that should do.
2532 Attribute handling
2534 Fortunately the DBI specifications allow a simple, but still performant
2536 way of handling attributes. The idea is based on the convention that
2537 any driver uses a prefix driver_ for its private methods. Thus it's
2538 always clear whether to pass attributes to the super class or not. For
2539 example, consider this STORE method from the DBD::CSV class:
2540 sub STORE {
2542 my ($dbh, $attr, $val) = @_;
2543 if ($attr !~ /^driver_/) {
2544 return $dbh->DBD::File::db::STORE($attr, $val);
2545 }
2546 if ($attr eq 'driver_foo') {
2547 ...
2548 }
2549
2551 Jonathan Leffler <jleffler@us.ibm.com> (previously <jlef‐
2552 fler@informix.com>), Jochen Wiedmann <joe@ispsoft.de>, Steffen Goeldner
2553 <sgoeldner@cpan.org>, and Tim Bunce <dbi-users@perl.org>.
2554perl v5.8.8 2006-02-07 DBI::DBD(3)