1DBI::DBD(3) User Contributed Perl Documentation DBI::DBD(3)
2
6 DBI::DBD - Perl DBI Database Driver Writer's Guide
7
9 perldoc DBI::DBD
10 Version and volatility
12 This document is still a minimal draft which is in need of further
13 work.
14 The changes will occur both because the DBI specification is changing
16 and hence the requirements on DBD drivers change, and because feedback
17 from people reading this document will suggest improvements to it.
18 Please read the DBI documentation first and fully, including the DBI
20 FAQ. Then reread the DBI specification again as you're reading this.
21 It'll help.
22 This document is a patchwork of contributions from various authors.
24 More contributions (preferably as patches) are very welcome.
25
27 This document is primarily intended to help people writing new database
28 drivers for the Perl Database Interface (Perl DBI). It may also help
29 others interested in discovering why the internals of a DBD driver are
30 written the way they are.
31 This is a guide. Few (if any) of the statements in it are completely
33 authoritative under all possible circumstances. This means you will
34 need to use judgement in applying the guidelines in this document. If
35 in any doubt at all, please do contact the dbi-dev mailing list
36 (details given below) where Tim Bunce and other driver authors can
37 help.
38
40 The first rule for creating a new database driver for the Perl DBI is
41 very simple: DON'T!
42 There is usually a driver already available for the database you want
44 to use, almost regardless of which database you choose. Very often, the
45 database will provide an ODBC driver interface, so you can often use
46 DBD::ODBC to access the database. This is typically less convenient on
47 a Unix box than on a Microsoft Windows box, but there are numerous
48 options for ODBC driver managers on Unix too, and very often the ODBC
49 driver is provided by the database supplier.
50 Before deciding that you need to write a driver, do your homework to
52 ensure that you 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
63 database more swiftly, or more comprehensively, than an ODBC driver
64 can. Then you should read this document very carefully, but with a
65 suitably sceptical eye.
66 If there is something in here that does not make any sense, question
68 it. You might be right that the information is bogus, but don't come
69 to that conclusion too quickly.
70 URLs and mailing lists
72 The primary web-site for locating DBI software and information is
73 http://dbi.perl.org/
75 There are two main and one auxiliary mailing lists for people working
77 with DBI. The primary lists are dbi-users@perl.org for general users
78 of DBI and DBD drivers, and dbi-dev@perl.org mainly for DBD driver
79 writers (don't join the dbi-dev list unless you have a good reason).
80 The auxiliary list is dbi-announce@perl.org for announcing new releases
81 of DBI or DBD drivers.
82 You can join these lists by accessing the web-site
84 <http://dbi.perl.org/>. The lists are closed so you cannot send email
85 to any of the lists unless you join the list first.
86 You should also consider monitoring the comp.lang.perl.* newsgroups,
88 especially comp.lang.perl.modules.
89 The Cheetah book
91 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 it.
96 Locating drivers
98 Before writing a new driver, it is in your interests to find out
99 whether there already is a driver for your database. If there is such
100 a driver, it would be much easier to make use of it than to write your
101 own!
102 The primary web-site for locating Perl software is
104 <http://search.cpan.org/>. You should look under the various modules
105 listings for the software you are after. For example:
106 http://search.cpan.org/modlist/Database_Interfaces
108 Follow the DBD:: and DBIx:: links at the top to see those subsets.
110 See the DBI docs for information on DBI web sites and mailing lists.
112 Registering a new driver
114 Before going through any official registration process, you will need
115 to establish that there is no driver already in the works. You'll do
116 that by asking the DBI mailing lists whether there is such a driver
117 available, or whether anybody is working on one.
118 When you get the go ahead, you will need to establish the name of the
120 driver and a prefix for the driver. Typically, the name is based on the
121 name of the database software it uses, and the prefix is a contraction
122 of that. Hence, DBD::Oracle has the name Oracle and the prefix 'ora_'.
123 The prefix must be lowercase and contain no underscores other than the
124 one at the end.
125 This information will be recorded in the DBI module. Apart from
127 documentation purposes, registration is a prerequisite for installing
128 private methods.
129 If you are writing a driver which will not be distributed on CPAN, then
131 you should choose a prefix beginning with 'x_', to avoid potential
132 prefix collisions with drivers registered in the future. Thus, if you
133 wrote a non-CPAN distributed driver called DBD::CustomDB, the prefix
134 might be 'x_cdb_'.
135 This document assumes you are writing a driver called DBD::Driver, and
137 that the prefix 'drv_' is assigned to the driver.
138 Two styles of database driver
140 There are two distinct styles of database driver that can be written to
141 work with the Perl DBI.
142 Your driver can be written in pure Perl, requiring no C compiler. When
144 feasible, this is the best solution, but most databases are not written
145 in such a way that this can be done. Some examples of pure Perl drivers
146 are DBD::File and DBD::CSV.
147 Alternatively, and most commonly, your driver will need to use some C
149 code to gain access to the database. This will be classified as a C/XS
150 driver.
151 What code will you write?
153 There are a number of files that need to be written for either a pure
154 Perl driver or a C/XS driver. There are no extra files needed only by a
155 pure Perl driver, but there are several extra files needed only by a
156 C/XS driver.
157 Files common to pure Perl and C/XS drivers
159 Assuming that your driver is called DBD::Driver, these files are:
161 · Makefile.PL
163 · META.yml
165 · README
167 · MANIFEST
169 · Driver.pm
171 · lib/Bundle/DBD/Driver.pm
173 · lib/DBD/Driver/Summary.pm
175 · t/*.t
177 The first four files are mandatory. Makefile.PL is used to control how
179 the driver is built and installed. The README file tells people who
180 download the file about how to build the module and any prerequisite
181 software that must be installed. The MANIFEST file is used by the
182 standard Perl module distribution mechanism. It lists all the source
183 files that need to be distributed with your module. Driver.pm is what
184 is loaded by the DBI code; it contains the methods peculiar to your
185 driver.
186 Although the META.yml file is not required you are advised to create
188 one. Of particular importance are the build_requires and
189 configure_requires attributes which newer CPAN modules understand. You
190 use these to tell the CPAN module (and CPANPLUS) that your build and
191 configure mechanisms require DBI. The best reference for META.yml (at
192 the time of writing) is
193 <http://module-build.sourceforge.net/META-spec-v1.2.html>. You can find
194 a reasonable example of a META.yml in DBD::ODBC.
195 The lib/Bundle/DBD/Driver.pm file allows you to specify other Perl
197 modules on which yours depends in a format that allows someone to type
198 a simple command and ensure that all the pre-requisites are in place as
199 well as building your driver.
200 The lib/DBD/Driver/Summary.pm file contains (an updated version of) the
202 information that was included - or that would have been included - in
203 the appendices of the Cheetah book as a summary of the abilities of
204 your driver and the associated database.
205 The files in the t subdirectory are unit tests for your driver. You
207 should write your tests as stringently as possible, while taking into
208 account the diversity of installations that you can encounter:
209 · Your tests should not casually modify operational databases.
211 · You should never damage existing tables in a database.
213 · You should code your tests to use a constrained name space within
215 the database. For example, the tables (and all other named objects)
216 that are created could all begin with 'dbd_drv_'.
217 · At the end of a test run, there should be no testing objects left
219 behind in the database.
220 · If you create any databases, you should remove them.
222 · If your database supports temporary tables that are automatically
224 removed at the end of a session, then exploit them as often as
225 possible.
226 · Try to make your tests independent of each other. If you have a
228 test t/t11dowhat.t that depends upon the successful running of
229 t/t10thingamy.t, people cannot run the single test case
230 t/t11dowhat.t. Further, running t/t11dowhat.t twice in a row is
231 likely to fail (at least, if t/t11dowhat.t modifies the database at
232 all) because the database at the start of the second run is not
233 what you saw at the start of the first run.
234 · Document in your README file what you do, and what privileges
236 people need to do it.
237 · You can, and probably should, sequence your tests by including a
239 test number before an abbreviated version of the test name; the
240 tests are run in the order in which the names are expanded by
241 shell-style globbing.
242 · It is in your interests to ensure that your tests work as widely as
244 possible.
245 Many drivers also install sub-modules DBD::Driver::SubModule for any of
247 a variety of different reasons, such as to support the metadata methods
248 (see the discussion of "METADATA METHODS" below). Such sub-modules are
249 conventionally stored in the directory lib/DBD/Driver. The module
250 itself would usually be in a file SubModule.pm. All such sub-modules
251 should themselves be version stamped (see the discussions far below).
252 Extra files needed by C/XS drivers
254 The software for a C/XS driver will typically contain at least four
256 extra files that are not relevant to a pure Perl driver.
257 · Driver.xs
259 · Driver.h
261 · dbdimp.h
263 · dbdimp.c
265 The Driver.xs file is used to generate C code that Perl can call to
267 gain access to the C functions you write that will, in turn, call down
268 onto your database software.
269 The Driver.h header is a stylized header that ensures you can access
271 the necessary Perl and DBI macros, types, and function declarations.
272 The dbdimp.h is used to specify which functions have been implemented
274 by your driver.
275 The dbdimp.c file is where you write the C code that does the real work
277 of translating between Perl-ish data types and what the database
278 expects to use and return.
279 There are some (mainly small, but very important) differences between
281 the contents of Makefile.PL and Driver.pm for pure Perl and C/XS
282 drivers, so those files are described both in the section on creating a
283 pure Perl driver and in the section on creating a C/XS driver.
284 Obviously, you can add extra source code files to the list.
286 Requirements on a driver and driver writer
288 To be remotely useful, your driver must be implemented in a format that
289 allows it to be distributed via CPAN, the Comprehensive Perl Archive
290 Network (<http://www.cpan.org/> and <http://search.cpan.org>). Of
291 course, it is easier if you do not have to meet this criterion, but you
292 will not be able to ask for much help if you do not do so, and no-one
293 is likely to want to install your module if they have to learn a new
294 installation mechanism.
295
297 Writing a pure Perl driver is surprisingly simple. However, there are
298 some problems you should be aware of. The best option is of course
299 picking up an existing driver and carefully modifying one method after
300 the other.
301 Also look carefully at DBD::AnyData and DBD::Template.
303 As an example we take a look at the DBD::File driver, a driver for
305 accessing plain files as tables, which is part of the DBD::CSV package.
306 The minimal set of files we have to implement are Makefile.PL, README,
308 MANIFEST and Driver.pm.
309 Pure Perl version of Makefile.PL
311 You typically start with writing Makefile.PL, a Makefile generator. The
312 contents of this file are described in detail in the
313 ExtUtils::MakeMaker man pages. It is definitely a good idea if you
314 start reading them. At least you should know about the variables
315 CONFIGURE, DEFINED, PM, DIR, EXE_FILES, INC, LIBS, LINKTYPE, NAME,
316 OPTIMIZE, PL_FILES, VERSION, VERSION_FROM, clean, depend, realclean
317 from the ExtUtils::MakeMaker man page: these are used in almost any
318 Makefile.PL.
319 Additionally read the section on Overriding MakeMaker Methods and the
321 descriptions of the distcheck, disttest and dist targets: They will
322 definitely be useful for you.
323 Of special importance for DBI drivers is the postamble method from the
325 ExtUtils::MM_Unix man page.
326 For Emacs users, I recommend the libscan method, which removes Emacs
328 backup files (file names which end with a tilde '~') from lists of
329 files.
330 Now an example, I use the word "Driver" wherever you should insert your
332 driver's name:
333 # -*- perl -*-
335 use ExtUtils::MakeMaker;
337 WriteMakefile(
339 dbd_edit_mm_attribs( {
340 'NAME' => 'DBD::Driver',
341 'VERSION_FROM' => 'Driver.pm',
342 'INC' => '',
343 'dist' => { 'SUFFIX' => '.gz',
344 'COMPRESS' => 'gzip -9f' },
345 'realclean' => { FILES => '*.xsi' },
346 'PREREQ_PM' => '1.03',
347 'CONFIGURE' => sub {
348 eval {require DBI::DBD;};
349 if ($@) {
350 warn $@;
351 exit 0;
352 }
353 my $dbi_arch_dir = dbd_dbi_arch_dir();
354 if (exists($opts{INC})) {
355 return {INC => "$opts{INC} -I$dbi_arch_dir"};
356 } else {
357 return {INC => "-I$dbi_arch_dir"};
358 }
359 }
360 },
361 { create_pp_tests => 1})
362 );
363 package MY;
365 sub postamble { return main::dbd_postamble(@_); }
366 sub libscan {
367 my ($self, $path) = @_;
368 ($path =~ m/\~$/) ? undef : $path;
369 }
370 Note the calls to "dbd_edit_mm_attribs()" and "dbd_postamble()".
372 The second hash reference in the call to "dbd_edit_mm_attribs()"
374 (containing "create_pp_tests()") is optional; you should not use it
375 unless your driver is a pure Perl driver (that is, it does not use C
376 and XS code). Therefore, the call to "dbd_edit_mm_attribs()" is not
377 relevant for C/XS drivers and may be omitted; simply use the (single)
378 hash reference containing NAME etc as the only argument to
379 "WriteMakefile()".
380 Note that the "dbd_edit_mm_attribs()" code will fail if you do not have
382 a t sub-directory containing at least one test case.
383 PREREQ_PM tells MakeMaker that DBI (version 1.03 in this case) is
385 required for this module. This will issue a warning that DBI 1.03 is
386 missing if someone attempts to install your DBD without DBI 1.03. See
387 CONFIGURE below for why this does not work reliably in stopping cpan
388 testers failing your module if DBI is not installed.
389 CONFIGURE is a subroutine called by MakeMaker during "WriteMakefile".
391 By putting the "require DBI::DBD" in this section we can attempt to
392 load DBI::DBD but if it is missing we exit with success. As we exit
393 successfully without creating a Makefile when DBI::DBD is missing cpan
394 testers will not report a failure. This may seem at odds with PREREQ_PM
395 but PREREQ_PM does not cause "WriteMakefile" to fail (unless you also
396 specify PREREQ_FATAL which is strongly discouraged by MakeMaker) so
397 "WriteMakefile" would continue to call "dbd_dbi_arch_dir" and fail.
398 All drivers must use "dbd_postamble()" or risk running into problems.
400 Note the specification of VERSION_FROM; the named file (Driver.pm) will
402 be scanned for the first line that looks like an assignment to
403 $VERSION, and the subsequent text will be used to determine the version
404 number. Note the commentary in ExtUtils::MakeMaker on the subject of
405 correctly formatted version numbers.
406 If your driver depends upon external software (it usually will), you
408 will need to add code to ensure that your environment is workable
409 before the call to "WriteMakefile()". If you need to check for the
410 existence of an external library and perhaps modify INC to include the
411 paths to where the external library header files are located and you
412 cannot find the library or header files make sure you output a message
413 saying they cannot be found but "exit 0" (success) before calling
414 "WriteMakefile" or CPAN testers will fail your module if the external
415 library is not found.
416 A full-fledged Makefile.PL can be quite large (for example, the files
418 for DBD::Oracle and DBD::Informix are both over 1000 lines long, and
419 the Informix one uses - and creates - auxiliary modules too).
420 See also ExtUtils::MakeMaker and ExtUtils::MM_Unix. Consider using
422 CPAN::MakeMaker in place of ExtUtils::MakeMaker.
423 README
425 The README file should describe what the driver is for, the pre-
426 requisites for the build process, the actual build process, how to
427 report errors, and who to report them to.
428 Users will find ways of breaking the driver build and test process
430 which you would never even have dreamed to be possible in your worst
431 nightmares. Therefore, you need to write this document defensively,
432 precisely and concisely.
433 As always, use the README from one of the established drivers as a
435 basis for your own; the version in DBD::Informix is worth a look as it
436 has been quite successful in heading off problems.
437 · Note that users will have versions of Perl and DBI that are both
439 older and newer than you expected, but this will seldom cause much
440 trouble. When it does, it will be because you are using features
441 of DBI that are not supported in the version they are using.
442 · Note that users will have versions of the database software that
444 are both older and newer than you expected. You will save yourself
445 time in the long run if you can identify the range of versions
446 which have been tested and warn about versions which are not known
447 to be OK.
448 · Note that many people trying to install your driver will not be
450 experts in the database software.
451 · Note that many people trying to install your driver will not be
453 experts in C or Perl.
454 MANIFEST
456 The MANIFEST will be used by the Makefile's dist target to build the
457 distribution tar file that is uploaded to CPAN. It should list every
458 file that you want to include in your distribution, one per line.
459 lib/Bundle/DBD/Driver.pm
461 The CPAN module provides an extremely powerful bundle mechanism that
462 allows you to specify pre-requisites for your driver.
463 The primary pre-requisite is Bundle::DBI; you may want or need to add
465 some more. With the bundle set up correctly, the user can type:
466 perl -MCPAN -e 'install Bundle::DBD::Driver'
468 and Perl will download, compile, test and install all the Perl modules
470 needed to build your driver.
471 The prerequisite modules are listed in the "CONTENTS" section, with the
473 official name of the module followed by a dash and an informal name or
474 description.
475 · Listing Bundle::DBI as the main pre-requisite simplifies life.
477 · Don't forget to list your driver.
479 · Note that unless the DBMS is itself a Perl module, you cannot list
481 it as a pre-requisite in this file.
482 · You should keep the version of the bundle the same as the version
484 of your driver.
485 · You should add configuration management, copyright, and licencing
487 information at the top.
488 A suitable skeleton for this file is shown below.
490 package Bundle::DBD::Driver;
492 $VERSION = '0.01';
494 1;
496 __END__
498 =head1 NAME
500 Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules
502 =head1 SYNOPSIS
504 C<perl -MCPAN -e 'install Bundle::DBD::Driver'>
506 =head1 CONTENTS
508 Bundle::DBI - Bundle for DBI by TIMB (Tim Bunce)
510 DBD::Driver - DBD::Driver by YOU (Your Name)
512 =head1 DESCRIPTION
514 This bundle includes all the modules used by the Perl Database
516 Interface (DBI) driver for Driver (DBD::Driver), assuming the
517 use of DBI version 1.13 or later, created by Tim Bunce.
518 If you've not previously used the CPAN module to install any
520 bundles, you will be interrogated during its setup phase.
521 But when you've done it once, it remembers what you told it.
522 You could start by running:
523 C<perl -MCPAN -e 'install Bundle::CPAN'>
525 =head1 SEE ALSO
527 Bundle::DBI
529 =head1 AUTHOR
531 Your Name E<lt>F<you@yourdomain.com>E<gt>
533 =head1 THANKS
535 This bundle was created by ripping off Bundle::libnet created by
537 Graham Barr E<lt>F<gbarr@ti.com>E<gt>, and radically simplified
538 with some information from Jochen Wiedmann E<lt>F<joe@ispsoft.de>E<gt>.
539 The template was then included in the DBI::DBD documentation by
540 Jonathan Leffler E<lt>F<jleffler@informix.com>E<gt>.
541 =cut
543 lib/DBD/Driver/Summary.pm
545 There is no substitute for taking the summary file from a driver that
546 was documented in the Perl book (such as DBD::Oracle or DBD::Informix
547 or DBD::ODBC, to name but three), and adapting it to describe the
548 facilities available via DBD::Driver when accessing the Driver
549 database.
550 Pure Perl version of Driver.pm
552 The Driver.pm file defines the Perl module DBD::Driver for your driver.
553 It will define a package DBD::Driver along with some version
554 information, some variable definitions, and a function "driver()" which
555 will have a more or less standard structure.
556 It will also define three sub-packages of DBD::Driver:
558 DBD::Driver::dr
560 with methods "connect()", "data_sources()" and "disconnect_all()";
561 DBD::Driver::db
563 with methods such as "prepare()";
564 DBD::Driver::st
566 with methods such as "execute()" and "fetch()".
567 The Driver.pm file will also contain the documentation specific to
569 DBD::Driver in the format used by perldoc.
570 In a pure Perl driver, the Driver.pm file is the core of the
572 implementation. You will need to provide all the key methods needed by
573 DBI.
574 Now let's take a closer look at an excerpt of File.pm as an example.
576 We ignore things that are common to any module (even non-DBI modules)
577 or really specific to the DBD::File package.
578 The DBD::Driver package
580 The header
582 package DBD::File;
584 use strict;
586 use vars qw($VERSION $drh);
587 $VERSION = "1.23.00" # Version number of DBD::File
589 This is where the version number of your driver is specified, and is
591 where Makefile.PL looks for this information. Please ensure that any
592 other modules added with your driver are also version stamped so that
593 CPAN does not get confused.
594 It is recommended that you use a two-part (1.23) or three-part
596 (1.23.45) version number. Also consider the CPAN system, which gets
597 confused and considers version 1.10 to precede version 1.9, so that
598 using a raw CVS, RCS or SCCS version number is probably not appropriate
599 (despite being very common).
600 For Subversion you could use:
602 $VERSION = sprintf("12.%06d", q$Revision: 12345 $ =~ /(\d+)/o);
604 (use lots of leading zeros on the second portion so if you move the
606 code to a shared repository like svn.perl.org the much larger revision
607 numbers won't cause a problem, at least not for a few years). For RCS
608 or CVS you can use:
609 $VERSION = sprintf "%d.%02d", '$Revision: 11.21 $ ' =~ /(\d+)\.(\d+)/;
611 which pads out the fractional part with leading zeros so all is well
613 (so long as you don't go past x.99)
614 $drh = undef; # holds driver handle once initialized
616 This is where the driver handle will be stored, once created. Note
618 that you may assume there is only one handle for your driver.
619 The driver constructor
621 The "driver()" method is the driver handle constructor. Note that the
623 "driver()" method is in the DBD::Driver package, not in one of the sub-
624 packages DBD::Driver::dr, DBD::Driver::db, or DBD::Driver::db.
625 sub driver
627 {
628 return $drh if $drh; # already created - return same one
629 my ($class, $attr) = @_;
630 $class .= "::dr";
632 DBD::Driver::db->install_method('drv_example_dbh_method');
634 DBD::Driver::st->install_method('drv_example_sth_method');
635 # not a 'my' since we use it above to prevent multiple drivers
637 $drh = DBI::_new_drh($class, {
638 'Name' => 'File',
639 'Version' => $VERSION,
640 'Attribution' => 'DBD::File by Jochen Wiedmann',
641 })
642 or return undef;
643 return $drh;
645 }
646 This is a reasonable example of how DBI implements its handles. There
648 are three kinds: driver handles (typically stored in $drh; from now on
649 called drh or $drh), database handles (from now on called dbh or $dbh)
650 and statement handles (from now on called sth or $sth).
651 The prototype of "DBI::_new_drh()" is
653 $drh = DBI::_new_drh($class, $public_attrs, $private_attrs);
655 with the following arguments:
657 $class
659 is typically the class for your driver, (for example,
660 "DBD::File::dr"), passed as the first argument to the "driver()"
661 method.
662 $public_attrs
664 is a hash ref to attributes like Name, Version, and Attribution.
665 These are processed and used by DBI. You had better not make any
666 assumptions about them nor should you add private attributes here.
667 $private_attrs
669 This is another (optional) hash ref with your private attributes.
670 DBI will store them and otherwise leave them alone.
671 The "DBI::_new_drh()" method and the "driver()" method both return
673 "undef" for failure (in which case you must look at $DBI::err and
674 $DBI::errstr for the failure information, because you have no driver
675 handle to use).
676 Using install_method() to expose driver-private methods
678 DBD::Foo::db->install_method($method_name, \%attr);
680 Installs the driver-private method named by $method_name into the DBI
682 method dispatcher so it can be called directly, avoiding the need to
683 use the func() method.
684 It is called as a static method on the driver class to which the method
686 belongs. The method name must begin with the corresponding registered
687 driver-private prefix. For example, for DBD::Oracle $method_name must
688 being with '"ora_"', and for DBD::AnyData it must begin with '"ad_"'.
689 The attributes can be used to provide fine control over how the DBI
691 dispatcher handles the dispatching of the method. However, at this
692 point, it's undocumented and very liable to change. (Volunteers to
693 polish up and document the interface are very welcome to get in touch
694 via dbi-dev@perl.org)
695 Methods installed using install_method default to the standard error
697 handling behaviour for DBI methods: clearing err and errstr before
698 calling the method, and checking for errors to trigger RaiseError etc.
699 on return. This differs from the default behaviour of func().
700 Note for driver authors: The DBD::Foo::xx->install_method call won't
702 work until the class-hierarchy has been setup. Normally the DBI looks
703 after that just after the driver is loaded. This means install_method()
704 can't be called at the time the driver is loaded unless the class-
705 hierarchy is set up first. The way to do that is to call the
706 setup_driver() method:
707 DBI->setup_driver('DBD::Foo');
709 before using install_method().
711 The CLONE special subroutine
713 Also needed here, in the DBD::Driver package, is a "CLONE()" method
715 that will be called by perl when an interpreter is cloned. All your
716 "CLONE()" method needs to do, currently, is clear the cached $drh so
717 the new interpreter won't start using the cached $drh from the old
718 interpreter:
719 sub CLONE {
721 undef $drh;
722 }
723 See
725 <http://search.cpan.org/dist/perl/pod/perlmod.pod#Making_your_module_threadsafe>
726 for details.
727 The DBD::Driver::dr package
729 The next lines of code look as follows:
731 package DBD::Driver::dr; # ====== DRIVER ======
733 $DBD::Driver::dr::imp_data_size = 0;
735 Note that no @ISA is needed here, or for the other DBD::Driver::*
737 classes, because the DBI takes care of that for you when the driver is
738 loaded.
739 *FIX ME* Explain what the imp_data_size is, so that implementors aren't
741 practicing cargo-cult programming.
742 The database handle constructor
744 The database handle constructor is the driver's (hence the changed
746 namespace) "connect()" method:
747 sub connect
749 {
750 my ($drh, $dr_dsn, $user, $auth, $attr) = @_;
751 # Some database specific verifications, default settings
753 # and the like can go here. This should only include
754 # syntax checks or similar stuff where it's legal to
755 # 'die' in case of errors.
756 # For example, many database packages requires specific
757 # environment variables to be set; this could be where you
758 # validate that they are set, or default them if they are not set.
759 my $driver_prefix = "drv_"; # the assigned prefix for this driver
761 # Process attributes from the DSN; we assume ODBC syntax
763 # here, that is, the DSN looks like var1=val1;...;varN=valN
764 foreach my $var ( split /;/, $dr_dsn ) {
765 my ($attr_name, $attr_value) = split '=', $var, 2;
766 return $drh->set_err($DBI::stderr, "Can't parse DSN part '$var'")
767 unless defined $attr_value;
768 # add driver prefix to attribute name if it doesn't have it already
770 $attr_name = $driver_prefix.$attr_name
771 unless $attr_name =~ /^$driver_prefix/o;
772 # Store attribute into %$attr, replacing any existing value.
774 # The DBI will STORE() these into $dbh after we've connected
775 $attr->{$attr_name} = $attr_value;
776 }
777 # Get the attributes we'll use to connect.
779 # We use delete here because these no need to STORE them
780 my $db = delete $attr->{drv_database} || delete $attr->{drv_db}
781 or return $drh->set_err($DBI::stderr, "No database name given in DSN '$dr_dsn'");
782 my $host = delete $attr->{drv_host} || 'localhost';
783 my $port = delete $attr->{drv_port} || 123456;
784 # Assume you can attach to your database via drv_connect:
786 my $connection = drv_connect($db, $host, $port, $user, $auth)
787 or return $drh->set_err($DBI::stderr, "Can't connect to $dr_dsn: ...");
788 # create a 'blank' dbh (call superclass constructor)
790 my ($outer, $dbh) = DBI::_new_dbh($drh, { Name => $dr_dsn });
791 $dbh->STORE('Active', 1 );
793 $dbh->{drv_connection} = $connection;
794 return $outer;
796 }
797 This is mostly the same as in the driver handle constructor above. The
799 arguments are described in DBI.
800 The constructor "DBI::_new_dbh()" is called, returning a database
802 handle. The constructor's prototype is:
803 ($outer, $inner) = DBI::_new_dbh($drh, $public_attr, $private_attr);
805 with similar arguments to those in the driver handle constructor,
807 except that the $class is replaced by $drh. The Name attribute is a
808 standard DBI attribute (see "Database Handle Attributes" in DBI).
809 In scalar context, only the outer handle is returned.
811 Note the use of the "STORE()" method for setting the dbh attributes.
813 That's because within the driver code, the handle object you have is
814 the 'inner' handle of a tied hash, not the outer handle that the users
815 of your driver have.
816 Because you have the inner handle, tie magic doesn't get invoked when
818 you get or set values in the hash. This is often very handy for speed
819 when you want to get or set simple non-special driver-specific
820 attributes.
821 However, some attribute values, such as those handled by the DBI like
823 PrintError, don't actually exist in the hash and must be read via
824 "$h->FETCH($attrib)" and set via "$h->STORE($attrib, $value)". If in
825 any doubt, use these methods.
826 The data_sources() method
828 The "data_sources()" method must populate and return a list of valid
830 data sources, prefixed with the "dbi:Driver" incantation that allows
831 them to be used in the first argument of the "DBI->connect()" method.
832 An example of this might be scanning the $HOME/.odbcini file on Unix
833 for ODBC data sources (DSNs).
834 As a trivial example, consider a fixed list of data sources:
836 sub data_sources
838 {
839 my($drh, $attr) = @_;
840 my(@list) = ();
841 # You need more sophisticated code than this to set @list...
842 push @list, "dbi:Driver:abc";
843 push @list, "dbi:Driver:def";
844 push @list, "dbi:Driver:ghi";
845 # End of code to set @list
846 return @list;
847 }
848 The disconnect_all() method
850 If you need to release any resources when the driver is unloaded, you
852 can provide a disconnect_all method.
853 Other driver handle methods
855 If you need any other driver handle methods, they can follow here.
857 Error handling
859 It is quite likely that something fails in the connect method. With
861 DBD::File for example, you might catch an error when setting the
862 current directory to something not existent by using the (driver-
863 specific) f_dir attribute.
864 To report an error, you use the "set_err()" method:
866 $h->set_err($err, $errmsg, $state);
868 This will ensure that the error is recorded correctly and that
870 RaiseError and PrintError etc are handled correctly.
871 Typically you'll always use the method instance, aka your method's
873 first argument.
874 As "set_err()" always returns "undef" your error handling code can
876 usually be simplified to something like this:
877 return $h->set_err($err, $errmsg, $state) if ...;
879 The DBD::Driver::db package
881 package DBD::Driver::db; # ====== DATABASE ======
883 $DBD::Driver::db::imp_data_size = 0;
885 The statement handle constructor
887 There's nothing much new in the statement handle constructor, which is
889 the "prepare()" method:
890 sub prepare
892 {
893 my ($dbh, $statement, @attribs) = @_;
894 # create a 'blank' sth
896 my ($outer, $sth) = DBI::_new_sth($dbh, { Statement => $statement });
897 $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//));
899 $sth->{drv_params} = [];
901 return $outer;
903 }
904 This is still the same -- check the arguments and call the super class
906 constructor "DBI::_new_sth()". Again, in scalar context, only the outer
907 handle is returned. The Statement attribute should be cached as shown.
908 Note the prefix drv_ in the attribute names: it is required that all
910 your private attributes use a lowercase prefix unique to your driver.
911 As mentioned earlier in this document, the DBI contains a registry of
912 known driver prefixes and may one day warn about unknown attributes
913 that don't have a registered prefix.
914 Note that we parse the statement here in order to set the attribute
916 NUM_OF_PARAMS. The technique illustrated is not very reliable; it can
917 be confused by question marks appearing in quoted strings, delimited
918 identifiers or in SQL comments that are part of the SQL statement. We
919 could set NUM_OF_PARAMS in the "execute()" method instead because the
920 DBI specification explicitly allows a driver to defer this, but then
921 the user could not call "bind_param()".
922 Transaction handling
924 Pure Perl drivers will rarely support transactions. Thus your
926 "commit()" and "rollback()" methods will typically be quite simple:
927 sub commit
929 {
930 my ($dbh) = @_;
931 if ($dbh->FETCH('Warn')) {
932 warn("Commit ineffective while AutoCommit is on");
933 }
934 0;
935 }
936 sub rollback {
938 my ($dbh) = @_;
939 if ($dbh->FETCH('Warn')) {
940 warn("Rollback ineffective while AutoCommit is on");
941 }
942 0;
943 }
944 Or even simpler, just use the default methods provided by the DBI that
946 do nothing except return "undef".
947 The DBI's default "begin_work()" method can be used by inheritance.
949 The STORE() and FETCH() methods
951 These methods (that we have already used, see above) are called for
953 you, whenever the user does a:
954 $dbh->{$attr} = $val;
956 or, respectively,
958 $val = $dbh->{$attr};
960 See perltie for details on tied hash refs to understand why these
962 methods are required.
963 The DBI will handle most attributes for you, in particular attributes
965 like RaiseError or PrintError. All you have to do is handle your
966 driver's private attributes and any attributes, like AutoCommit and
967 ChopBlanks, that the DBI can't handle for you.
968 A good example might look like this:
970 sub STORE
972 {
973 my ($dbh, $attr, $val) = @_;
974 if ($attr eq 'AutoCommit') {
975 # AutoCommit is currently the only standard attribute we have
976 # to consider.
977 if (!$val) { die "Can't disable AutoCommit"; }
978 return 1;
979 }
980 if ($attr =~ m/^drv_/) {
981 # Handle only our private attributes here
982 # Note that we could trigger arbitrary actions.
983 # Ideally we should warn about unknown attributes.
984 $dbh->{$attr} = $val; # Yes, we are allowed to do this,
985 return 1; # but only for our private attributes
986 }
987 # Else pass up to DBI to handle for us
988 $dbh->SUPER::STORE($attr, $val);
989 }
990 sub FETCH
992 {
993 my ($dbh, $attr) = @_;
994 if ($attr eq 'AutoCommit') { return 1; }
995 if ($attr =~ m/^drv_/) {
996 # Handle only our private attributes here
997 # Note that we could trigger arbitrary actions.
998 return $dbh->{$attr}; # Yes, we are allowed to do this,
999 # but only for our private attributes
1000 }
1001 # Else pass up to DBI to handle
1002 $dbh->SUPER::FETCH($attr);
1003 }
1004 The DBI will actually store and fetch driver-specific attributes (with
1006 all lowercase names) without warning or error, so there's actually no
1007 need to implement driver-specific any code in your "FETCH()" and
1008 "STORE()" methods unless you need extra logic/checks, beyond getting or
1009 setting the value.
1010 Unless your driver documentation indicates otherwise, the return value
1012 of the "STORE()" method is unspecified and the caller shouldn't use
1013 that value.
1014 Other database handle methods
1016 As with the driver package, other database handle methods may follow
1018 here. In particular you should consider a (possibly empty)
1019 "disconnect()" method and possibly a "quote()" method if DBI's default
1020 isn't correct for you. You may also need the "type_info_all()" and
1021 "get_info()" methods, as described elsewhere in this document.
1022 Where reasonable use "$h->SUPER::foo()" to call the DBI's method in
1024 some or all cases and just wrap your custom behavior around that.
1025 If you want to use private trace flags you'll probably want to be able
1027 to set them by name. To do that you'll need to define a
1028 "parse_trace_flag()" method (note that's "parse_trace_flag", singular,
1029 not "parse_trace_flags", plural).
1030 sub parse_trace_flag {
1032 my ($h, $name) = @_;
1033 return 0x01000000 if $name eq 'foo';
1034 return 0x02000000 if $name eq 'bar';
1035 return 0x04000000 if $name eq 'baz';
1036 return 0x08000000 if $name eq 'boo';
1037 return 0x10000000 if $name eq 'bop';
1038 return $h->SUPER::parse_trace_flag($name);
1039 }
1040 All private flag names must be lowercase, and all private flags must be
1042 in the top 8 of the 32 bits.
1043 The DBD::Driver::st package
1045 This package follows the same pattern the others do:
1047 package DBD::Driver::st;
1049 $DBD::Driver::st::imp_data_size = 0;
1051 The execute() and bind_param() methods
1053 This is perhaps the most difficult method because we have to consider
1055 parameter bindings here. In addition to that, there are a number of
1056 statement attributes which must be set for inherited DBI methods to
1057 function correctly (see "Statement attributes" below).
1058 We present a simplified implementation by using the drv_params
1060 attribute from above:
1061 sub bind_param
1063 {
1064 my ($sth, $pNum, $val, $attr) = @_;
1065 my $type = (ref $attr) ? $attr->{TYPE} : $attr;
1066 if ($type) {
1067 my $dbh = $sth->{Database};
1068 $val = $dbh->quote($sth, $type);
1069 }
1070 my $params = $sth->{drv_params};
1071 $params->[$pNum-1] = $val;
1072 1;
1073 }
1074 sub execute
1076 {
1077 my ($sth, @bind_values) = @_;
1078 # start of by finishing any previous execution if still active
1080 $sth->finish if $sth->FETCH('Active');
1081 my $params = (@bind_values) ?
1083 \@bind_values : $sth->{drv_params};
1084 my $numParam = $sth->FETCH('NUM_OF_PARAMS');
1085 return $sth->set_err($DBI::stderr, "Wrong number of parameters")
1086 if @$params != $numParam;
1087 my $statement = $sth->{'Statement'};
1088 for (my $i = 0; $i < $numParam; $i++) {
1089 $statement =~ s/?/$params->[$i]/; # XXX doesn't deal with quoting etc!
1090 }
1091 # Do anything ... we assume that an array ref of rows is
1092 # created and store it:
1093 $sth->{'drv_data'} = $data;
1094 $sth->{'drv_rows'} = @$data; # number of rows
1095 $sth->STORE('NUM_OF_FIELDS') = $numFields;
1096 $sth->{Active} = 1;
1097 @$data || '0E0';
1098 }
1099 There are a number of things you should note here.
1101 We initialize the NUM_OF_FIELDS and Active attributes here, because
1103 they are essential for "bind_columns()" to work.
1104 We use attribute "$sth->{Statement}" which we created within
1106 "prepare()". The attribute "$sth->{Database}", which is nothing else
1107 than the dbh, was automatically created by DBI.
1108 Finally, note that (as specified in the DBI specification) we return
1110 the string '0E0' instead of the number 0, so that the result tests true
1111 but equal to zero.
1112 $sth->execute() or die $sth->errstr;
1114 The execute_array(), execute_for_fetch() and bind_param_array() methods
1116 In general, DBD's only need to implement "execute_for_fetch()" and
1118 "bind_param_array". DBI's default "execute_array()" will invoke the
1119 DBD's "execute_for_fetch()" as needed.
1120 The following sequence describes the interaction between DBI
1122 "execute_array" and a DBD's "execute_for_fetch":
1123 1. App calls "$sth->execute_array(\%attrs, @array_of_arrays)"
1125 2. If @array_of_arrays was specified, DBI processes @array_of_arrays
1127 by calling DBD's "bind_param_array()". Alternately, App may have
1128 directly called "bind_param_array()"
1129 3. DBD validates and binds each array
1131 4. DBI retrieves the validated param arrays from DBD's ParamArray
1133 attribute
1134 5. DBI calls DBD's "execute_for_fetch($fetch_tuple_sub,
1136 \@tuple_status)", where &$fetch_tuple_sub is a closure to iterate
1137 over the returned ParamArray values, and "\@tuple_status" is an
1138 array to receive the disposition status of each tuple.
1139 6. DBD iteratively calls &$fetch_tuple_sub to retrieve parameter
1141 tuples to be added to its bulk database operation/request.
1142 7. when DBD reaches the limit of tuples it can handle in a single
1144 database operation/request, or the &$fetch_tuple_sub indicates no
1145 more tuples by returning undef, the DBD executes the bulk
1146 operation, and reports the disposition of each tuple in
1147 \@tuple_status.
1148 8. DBD repeats steps 6 and 7 until all tuples are processed.
1150 E.g., here's the essence of DBD::Oracle's execute_for_fetch:
1152 while (1) {
1154 my @tuple_batch;
1155 for (my $i = 0; $i < $batch_size; $i++) {
1156 push @tuple_batch, [ @{$fetch_tuple_sub->() || last} ];
1157 }
1158 last unless @tuple_batch;
1159 my $res = ora_execute_array($sth, \@tuple_batch,
1160 scalar(@tuple_batch), $tuple_batch_status);
1161 push @$tuple_status, @$tuple_batch_status;
1162 }
1163 Note that DBI's default execute_array()/execute_for_fetch()
1165 implementation requires the use of positional (i.e., '?') placeholders.
1166 Drivers which require named placeholders must either emulate positional
1167 placeholders (e.g., see DBD::Oracle), or must implement their own
1168 execute_array()/execute_for_fetch() methods to properly sequence bound
1169 parameter arrays.
1170 Fetching data
1172 Only one method needs to be written for fetching data,
1174 "fetchrow_arrayref()". The other methods, "fetchrow_array()",
1175 "fetchall_arrayref()", etc, as well as the database handle's "select*"
1176 methods are part of DBI, and call "fetchrow_arrayref()" as necessary.
1177 sub fetchrow_arrayref
1179 {
1180 my ($sth) = @_;
1181 my $data = $sth->{drv_data};
1182 my $row = shift @$data;
1183 if (!$row) {
1184 $sth->STORE(Active => 0); # mark as no longer active
1185 return undef;
1186 }
1187 if ($sth->FETCH('ChopBlanks')) {
1188 map { $_ =~ s/\s+$//; } @$row;
1189 }
1190 return $sth->_set_fbav($row);
1191 }
1192 *fetch = \&fetchrow_arrayref; # required alias for fetchrow_arrayref
1193 Note the use of the method "_set_fbav()" -- this is required so that
1195 "bind_col()" and "bind_columns()" work.
1196 If an error occurs which leaves the $sth in a state where remaining
1198 rows can't be fetched then Active should be turned off before the
1199 method returns.
1200 The "rows()" method for this driver can be implemented like this:
1202 sub rows { shift->{drv_rows} }
1204 because it knows in advance how many rows it has fetched.
1206 Alternatively you could delete that method and so fallback to the DBI's
1207 own method which does the right thing based on the number of calls to
1208 "_set_fbav()".
1209 The more_results method
1211 If your driver doesn't support multiple result sets, then don't even
1213 implement this method.
1214 Otherwise, this method needs to get the statement handle ready to fetch
1216 results from the next result set, if there is one. Typically you'd
1217 start with:
1218 $sth->finish;
1220 then you should delete all the attributes from the attribute cache that
1222 may no longer be relevant for the new result set:
1223 delete $sth->{$_}
1225 for qw(NAME TYPE PRECISION SCALE ...);
1226 for drivers written in C use:
1228 hv_delete((HV*)SvRV(sth), "NAME", 4, G_DISCARD);
1230 hv_delete((HV*)SvRV(sth), "NULLABLE", 8, G_DISCARD);
1231 hv_delete((HV*)SvRV(sth), "NUM_OF_FIELDS", 13, G_DISCARD);
1232 hv_delete((HV*)SvRV(sth), "PRECISION", 9, G_DISCARD);
1233 hv_delete((HV*)SvRV(sth), "SCALE", 5, G_DISCARD);
1234 hv_delete((HV*)SvRV(sth), "TYPE", 4, G_DISCARD);
1235 Don't forget to also delete, or update, any driver-private attributes
1237 that may not be correct for the next resultset.
1238 The NUM_OF_FIELDS attribute is a special case. It should be set using
1240 STORE:
1241 $sth->STORE(NUM_OF_FIELDS => 0); /* for DBI <= 1.53 */
1243 $sth->STORE(NUM_OF_FIELDS => $new_value);
1244 for drivers written in C use this incantation:
1246 /* Adjust NUM_OF_FIELDS - which also adjusts the row buffer size */
1248 DBIc_NUM_FIELDS(imp_sth) = 0; /* for DBI <= 1.53 */
1249 DBIc_STATE(imp_xxh)->set_attr_k(sth, sv_2mortal(newSVpvn("NUM_OF_FIELDS",13)), 0,
1250 sv_2mortal(newSViv(mysql_num_fields(imp_sth->result)))
1251 );
1252 For DBI versions prior to 1.54 you'll also need to explicitly adjust
1254 the number of elements in the row buffer array
1255 ("DBIc_FIELDS_AV(imp_sth)") to match the new result set. Fill any new
1256 values with newSV(0) not &sv_undef. Alternatively you could free
1257 DBIc_FIELDS_AV(imp_sth) and set it to null, but that would mean
1258 bind_columns() wouldn't work across result sets.
1259 Statement attributes
1261 The main difference between dbh and sth attributes is, that you should
1263 implement a lot of attributes here that are required by the DBI, such
1264 as NAME, NULLABLE, TYPE, etc. See "Statement Handle Attributes" in DBI
1265 for a complete list.
1266 Pay attention to attributes which are marked as read only, such as
1268 NUM_OF_PARAMS. These attributes can only be set the first time a
1269 statement is executed. If a statement is prepared, then executed
1270 multiple times, warnings may be generated.
1271 You can protect against these warnings, and prevent the recalculation
1273 of attributes which might be expensive to calculate (such as the NAME
1274 and NAME_* attributes):
1275 my $storedNumParams = $sth->FETCH('NUM_OF_PARAMS');
1277 if (!defined $storedNumParams or $storedNumFields < 0) {
1278 $sth->STORE('NUM_OF_PARAMS') = $numParams;
1279 # Set other useful attributes that only need to be set once
1281 # for a statement, like $sth->{NAME} and $sth->{TYPE}
1282 }
1283 One particularly important attribute to set correctly (mentioned in
1285 "ATTRIBUTES COMMON TO ALL HANDLES" in DBI is Active. Many DBI methods,
1286 including "bind_columns()", depend on this attribute.
1287 Besides that the "STORE()" and "FETCH()" methods are mainly the same as
1289 above for dbh's.
1290 Other statement methods
1292 A trivial "finish()" method to discard stored data, reset any
1294 attributes (such as Active) and do "$sth->SUPER::finish()".
1295 If you've defined a "parse_trace_flag()" method in ::db you'll also
1297 want it in ::st, so just alias it in:
1298 *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;
1300 And perhaps some other methods that are not part of the DBI
1302 specification, in particular to make metadata available. Remember that
1303 they must have names that begin with your drivers registered prefix so
1304 they can be installed using "install_method()".
1305 If "DESTROY()" is called on a statement handle that's still active
1307 ("$sth->{Active}" is true) then it should effectively call "finish()".
1308 sub DESTROY {
1310 my $sth = shift;
1311 $sth->finish if $sth->FETCH('Active');
1312 }
1313 Tests
1315 The test process should conform as closely as possibly to the Perl
1316 standard test harness.
1317 In particular, most (all) of the tests should be run in the t sub-
1319 directory, and should simply produce an "ok" when run under "make
1320 test". For details on how this is done, see the Camel book and the
1321 section in Chapter 7, "The Standard Perl Library" on Test::Harness.
1322 The tests may need to adapt to the type of database which is being used
1324 for testing, and to the privileges of the user testing the driver. For
1325 example, the DBD::Informix test code has to adapt in a number of places
1326 to the type of database to which it is connected as different Informix
1327 databases have different capabilities: some of the tests are for
1328 databases without transaction logs; others are for databases with a
1329 transaction log; some versions of the server have support for blobs, or
1330 stored procedures, or user-defined data types, and others do not.
1331 When a complete file of tests must be skipped, you can provide a reason
1333 in a pseudo-comment:
1334 if ($no_transactions_available)
1336 {
1337 print "1..0 # Skip: No transactions available\n";
1338 exit 0;
1339 }
1340 Consider downloading the DBD::Informix code and look at the code in
1342 DBD/Informix/TestHarness.pm which is used throughout the DBD::Informix
1343 tests in the t sub-directory.
1344
1346 Please also see the section under "CREATING A PURE PERL DRIVER"
1347 regarding the creation of the Makefile.PL.
1348 Creating a new C/XS driver from scratch will always be a daunting task.
1350 You can and should greatly simplify your task by taking a good
1351 reference driver implementation and modifying that to match the
1352 database product for which you are writing a driver.
1353 The de facto reference driver has been the one for DBD::Oracle written
1355 by Tim Bunce, who is also the author of the DBI package. The
1356 DBD::Oracle module is a good example of a driver implemented around a
1357 C-level API.
1358 Nowadays it it seems better to base on DBD::ODBC, another driver
1360 maintained by Tim and Jeff Urlwin, because it offers a lot of metadata
1361 and seems to become the guideline for the future development. (Also as
1362 DBD::Oracle digs deeper into the Oracle 8 OCI interface it'll get even
1363 more hairy than it is now.)
1364 The DBD::Informix driver is one driver implemented using embedded SQL
1366 instead of a function-based API. DBD::Ingres may also be worth a look.
1367 C/XS version of Driver.pm
1369 A lot of the code in the Driver.pm file is very similar to the code for
1370 pure Perl modules - see above. However, there are also some subtle
1371 (and not so subtle) differences, including:
1372 · The variables $DBD::Driver::{dr|db|st}::imp_data_size are not
1374 defined here, but in the XS code, because they declare the size
1375 of certain C structures.
1376 · Some methods are typically moved to the XS code, in particular
1378 "prepare()", "execute()", "disconnect()", "disconnect_all()"
1379 and the "STORE()" and "FETCH()" methods.
1380 · Other methods are still part of Driver.pm, but have callbacks
1382 to the XS code.
1383 · If the driver-specific parts of the imp_drh_t structure need to
1385 be formally initialized (which does not seem to be a common
1386 requirement), then you need to add a call to an appropriate XS
1387 function in the driver method of "DBD::Driver::driver()", and
1388 you define the corresponding function in Driver.xs, and you
1389 define the C code in dbdimp.c and the prototype in dbdimp.h.
1390 For example, DBD::Informix has such a requirement, and adds the
1392 following call after the call to "_new_drh()" in Informix.pm:
1393 DBD::Informix::dr::driver_init($drh);
1395 and the following code in Informix.xs:
1397 # Initialize the DBD::Informix driver data structure
1399 void
1400 driver_init(drh)
1401 SV *drh
1402 CODE:
1403 ST(0) = dbd_ix_dr_driver_init(drh) ? &sv_yes : &sv_no;
1404 and the code in dbdimp.h declares:
1406 extern int dbd_ix_dr_driver_init(SV *drh);
1408 and the code in dbdimp.ec (equivalent to dbdimp.c) defines:
1410 /* Formally initialize the DBD::Informix driver structure */
1412 int
1413 dbd_ix_dr_driver(SV *drh)
1414 {
1415 D_imp_drh(drh);
1416 imp_drh->n_connections = 0; /* No active connections */
1417 imp_drh->current_connection = 0; /* No current connection */
1418 imp_drh->multipleconnections = (ESQLC_VERSION >= 600) ? True : False;
1419 dbd_ix_link_newhead(&imp_drh->head); /* Empty linked list of connections */
1420 return 1;
1421 }
1422 DBD::Oracle has a similar requirement but gets around it by
1424 checking whether the private data part of the driver handle is
1425 all zeroed out, rather than add extra functions.
1426 Now let's take a closer look at an excerpt from Oracle.pm (revised
1428 heavily to remove idiosyncrasies) as an example, ignoring things that
1429 were already discussed for pure Perl drivers.
1430 The connect method
1432 The connect method is the database handle constructor. You could write
1434 either of two versions of this method: either one which takes
1435 connection attributes (new code) and one which ignores them (old code
1436 only).
1437 If you ignore the connection attributes, then you omit all mention of
1439 the $auth variable (which is a reference to a hash of attributes), and
1440 the XS system manages the differences for you.
1441 sub connect
1443 {
1444 my ($drh, $dbname, $user, $auth, $attr) = @_;
1445 # Some database specific verifications, default settings
1447 # and the like following here. This should only include
1448 # syntax checks or similar stuff where it's legal to
1449 # 'die' in case of errors.
1450 my $dbh = DBI::_new_dbh($drh, {
1452 'Name' => $dbname,
1453 })
1454 or return undef;
1455 # Call the driver-specific function _login in Driver.xs file which
1457 # calls the DBMS-specific function(s) to connect to the database,
1458 # and populate internal handle data.
1459 DBD::Driver::db::_login($dbh, $dbname, $user, $auth, $attr)
1460 or return undef;
1461 $dbh;
1463 }
1464 This is mostly the same as in the pure Perl case, the exception being
1466 the use of the private "_login()" callback, which is the function that
1467 will really connect to the database. It is implemented in Driver.xst
1468 (you should not implement it) and calls "dbd_db_login6()" or
1469 "dbd_db_login6_sv" from dbdimp.c. See below for details.
1470 If your driver has driver-specific attributes which may be passed in
1472 the connect method and hence end up in $attr in "dbd_db_login6" then it
1473 is best to delete any you process so DBI does not send them again via
1474 STORE after connect. You can do this in C like this:
1475 DBD_ATTRIB_DELETE(attr, "my_attribute_name",
1477 strlen("my_attribute_name"));
1478 However, prior to DBI subversion version 11605 (and fixed post 1.607)
1480 DBD_ATTRIB_DELETE segfaulted so if you cannot guarantee the DBI version
1481 will be post 1.607 you need to use:
1482 hv_delete((HV*)SvRV(attr), "my_attribute_name",
1484 strlen("my_attribute_name"), G_DISCARD);
1485 *FIX ME* Discuss removing attributes in Perl code.
1487 The disconnect_all method
1489 *FIX ME* T.B.S
1491 The data_sources method
1493 If your "data_sources()" method can be implemented in pure Perl, then
1495 do so because it is easier than doing it in XS code (see the section
1496 above for pure Perl drivers).
1497 If your "data_sources()" method must call onto compiled functions, then
1499 you will need to define dbd_dr_data_sources in your dbdimp.h file,
1500 which will trigger Driver.xst (in DBI v1.33 or greater) to generate the
1501 XS code that calls your actual C function (see the discussion below for
1502 details) and you do not code anything in Driver.pm to handle it.
1503 The prepare method
1505 The prepare method is the statement handle constructor, and most of it
1507 is not new. Like the "connect()" method, it now has a C callback:
1508 package DBD::Driver::db; # ====== DATABASE ======
1510 use strict;
1511 sub prepare
1513 {
1514 my ($dbh, $statement, $attribs) = @_;
1515 # create a 'blank' sth
1517 my $sth = DBI::_new_sth($dbh, {
1518 'Statement' => $statement,
1519 })
1520 or return undef;
1521 # Call the driver-specific function _prepare in Driver.xs file
1523 # which calls the DBMS-specific function(s) to prepare a statement
1524 # and populate internal handle data.
1525 DBD::Driver::st::_prepare($sth, $statement, $attribs)
1526 or return undef;
1527 $sth;
1528 }
1529 The execute method
1531 *FIX ME* T.B.S
1533 The fetchrow_arrayref method
1535 *FIX ME* T.B.S
1537 Other methods?
1539 *FIX ME* T.B.S
1541 Driver.xs
1543 Driver.xs should look something like this:
1544 #include "Driver.h"
1546 DBISTATE_DECLARE;
1548 INCLUDE: Driver.xsi
1550 MODULE = DBD::Driver PACKAGE = DBD::Driver::dr
1552 /* Non-standard drh XS methods following here, if any. */
1554 /* If none (the usual case), omit the MODULE line above too. */
1555 MODULE = DBD::Driver PACKAGE = DBD::Driver::db
1557 /* Non-standard dbh XS methods following here, if any. */
1559 /* Currently this includes things like _list_tables from */
1560 /* DBD::mSQL and DBD::mysql. */
1561 MODULE = DBD::Driver PACKAGE = DBD::Driver::st
1563 /* Non-standard sth XS methods following here, if any. */
1565 /* In particular this includes things like _list_fields from */
1566 /* DBD::mSQL and DBD::mysql for accessing metadata. */
1567 Note especially the include of Driver.xsi here: DBI inserts stub
1569 functions for almost all private methods here which will typically do
1570 much work for you.
1571 Wherever you really have to implement something, it will call a private
1573 function in dbdimp.c, and this is what you have to implement.
1574 You need to set up an extra routine if your driver needs to export
1576 constants of its own, analogous to the SQL types available when you
1577 say:
1578 use DBI qw(:sql_types);
1580 *FIX ME* T.B.S
1582 Driver.h
1584 Driver.h is very simple and the operational contents should look like
1585 this:
1586 #ifndef DRIVER_H_INCLUDED
1588 #define DRIVER_H_INCLUDED
1589 #define NEED_DBIXS_VERSION 93 /* 93 for DBI versions 1.00 to 1.51+ */
1591 #define PERL_NO_GET_CONTEXT /* if used require DBI 1.51+ */
1592 #include <DBIXS.h> /* installed by the DBI module */
1594 #include "dbdimp.h"
1596 #include "dbivport.h" /* see below */
1598 #include <dbd_xsh.h> /* installed by the DBI module */
1600 #endif /* DRIVER_H_INCLUDED */
1602 The DBIXS.h header defines most of the interesting information that the
1604 writer of a driver needs.
1605 The file dbd_xsh.h header provides prototype declarations for the C
1607 functions that you might decide to implement. Note that you should
1608 normally only define one of "dbd_db_login()", "dbd_db_login6()" or
1609 "dbd_db_login6_sv" unless you are intent on supporting really old
1610 versions of DBI (prior to DBI 1.06) as well as modern versions. The
1611 only standard, DBI-mandated functions that you need write are those
1612 specified in the dbd_xsh.h header. You might also add extra driver-
1613 specific functions in Driver.xs.
1614 The dbivport.h file should be copied from the latest DBI release into
1616 your distribution each time you modify your driver. Its job is to allow
1617 you to enhance your code to work with the latest DBI API while still
1618 allowing your driver to be compiled and used with older versions of the
1619 DBI (for example, when the "DBIh_SET_ERR_CHAR()" macro was added to DBI
1620 1.41, an emulation of it was added to dbivport.h). This makes users
1621 happy and your life easier. Always read the notes in dbivport.h to
1622 check for any limitations in the emulation that you should be aware of.
1623 With DBI v1.51 or better I recommend that the driver defines
1625 PERL_NO_GET_CONTEXT before DBIXS.h is included. This can significantly
1626 improve efficiency when running under a thread enabled perl. (Remember
1627 that the standard perl in most Linux distributions is built with
1628 threads enabled. So is ActiveState perl for Windows, and perl built
1629 for Apache mod_perl2.) If you do this there are some things to keep in
1630 mind:
1631 · If PERL_NO_GET_CONTEXT is defined, then every function that calls
1633 the Perl API will need to start out with a "dTHX;" declaration.
1634 · You'll know which functions need this, because the C compiler will
1636 complain that the undeclared identifier "my_perl" is used if and
1637 only if the perl you are using to develop and test your driver has
1638 threads enabled.
1639 · If you don't remember to test with a thread-enabled perl before
1641 making a release it's likely that you'll get failure reports from
1642 users who are.
1643 · For driver private functions it is possible to gain even more
1645 efficiency by replacing "dTHX;" with "pTHX_" prepended to the
1646 parameter list and then "aTHX_" prepended to the argument list
1647 where the function is called.
1648 See "How multiple interpreters and concurrency are supported" in
1650 perlguts for additional information about PERL_NO_GET_CONTEXT.
1651 Implementation header dbdimp.h
1653 This header file has two jobs:
1654 First it defines data structures for your private part of the handles.
1656 Second it defines macros that rename the generic names like
1658 "dbd_db_login()" to database specific names like "ora_db_login()". This
1659 avoids name clashes and enables use of different drivers when you work
1660 with a statically linked perl.
1661 It also will have the important task of disabling XS methods that you
1663 don't want to implement.
1664 Finally, the macros will also be used to select alternate
1666 implementations of some functions. For example, the "dbd_db_login()"
1667 function is not passed the attribute hash.
1668 Since DBI v1.06, if a "dbd_db_login6()" macro is defined (for a
1670 function with 6 arguments), it will be used instead with the attribute
1671 hash passed as the sixth argument.
1672 Since DBI post v1.607, if a "dbd_db_login6_sv()" macro is defined (for
1674 a function like dbd_db_login6 but with scalar pointers for the dbname,
1675 username and password), it will be used instead. This will allow your
1676 login6 function to see if there are any unicode characters in the
1677 dbname.
1678 People used to just pick Oracle's dbdimp.c and use the same names,
1680 structures and types. I strongly recommend against that. At first
1681 glance this saves time, but your implementation will be less readable.
1682 It was just hell when I had to separate DBI specific parts, Oracle
1683 specific parts, mSQL specific parts and mysql specific parts in
1684 DBD::mysql's dbdimp.h and dbdimp.c. (DBD::mysql was a port of DBD::mSQL
1685 which was based on DBD::Oracle.) [Seconded, based on the experience
1686 taking DBD::Informix apart, even though the version inherited in 1996
1687 was only based on DBD::Oracle.]
1688 This part of the driver is your exclusive part. Rewrite it from
1690 scratch, so it will be clean and short: in other words, a better piece
1691 of code. (Of course keep an eye on other people's work.)
1692 struct imp_drh_st {
1694 dbih_drc_t com; /* MUST be first element in structure */
1695 /* Insert your driver handle attributes here */
1696 };
1697 struct imp_dbh_st {
1699 dbih_dbc_t com; /* MUST be first element in structure */
1700 /* Insert your database handle attributes here */
1701 };
1702 struct imp_sth_st {
1704 dbih_stc_t com; /* MUST be first element in structure */
1705 /* Insert your statement handle attributes here */
1706 };
1707 /* Rename functions for avoiding name clashes; prototypes are */
1709 /* in dbd_xst.h */
1710 #define dbd_init drv_dr_init
1711 #define dbd_db_login6_sv drv_db_login_sv
1712 #define dbd_db_do drv_db_do
1713 ... many more here ...
1714 These structures implement your private part of the handles.
1716 You have to use the name "imp_dbh_{dr|db|st}" and the first field must
1718 be of type dbih_drc_t|_dbc_t|_stc_t and must be called "com".
1719 You should never access these fields directly, except by using the
1721 DBIc_xxx() macros below.
1722 Implementation source dbdimp.c
1724 Conventionally, dbdimp.c is the main implementation file (but
1725 DBD::Informix calls the file dbdimp.ec). This section includes a short
1726 note on each function that is used in the Driver.xsi template and thus
1727 has to be implemented.
1728 Of course, you will probably also need to implement other support
1730 functions, which should usually be file static if they are placed in
1731 dbdimp.c. If they are placed in other files, you need to list those
1732 files in Makefile.PL (and MANIFEST) to handle them correctly.
1733 It is wise to adhere to a namespace convention for your functions to
1735 avoid conflicts. For example, for a driver with prefix drv_, you might
1736 call externally visible functions dbd_drv_xxxx. You should also avoid
1737 non-constant global variables as much as possible to improve the
1738 support for threading.
1739 Since Perl requires support for function prototypes (ANSI or ISO or
1741 Standard C), you should write your code using function prototypes too.
1742 It is possible to use either the unmapped names such as "dbd_init()" or
1744 the mapped names such as "dbd_ix_dr_init()" in the dbdimp.c file.
1745 DBD::Informix uses the mapped names which makes it easier to identify
1746 where to look for linkage problems at runtime (which will report errors
1747 using the mapped names).
1748 Most other drivers, and in particular DBD::Oracle, use the unmapped
1750 names in the source code which makes it a little easier to compare code
1751 between drivers and eases discussions on the dbi-dev mailing list. The
1752 majority of the code fragments here will use the unmapped names.
1753 Ultimately, you should provide implementations for most of the
1755 functions listed in the dbd_xsh.h header. The exceptions are optional
1756 functions (such as "dbd_st_rows()") and those functions with
1757 alternative signatures, such as "dbd_db_login6_sv", "dbd_db_login6()"
1758 and dbd_db_login(). Then you should only implement one of the
1759 alternatives, and generally the newer one of the alternatives.
1760 The dbd_init method
1762 #include "Driver.h"
1764 DBISTATE_DECLARE;
1766 void dbd_init(dbistate_t* dbistate)
1768 {
1769 DBISTATE_INIT; /* Initialize the DBI macros */
1770 }
1771 The "dbd_init()" function will be called when your driver is first
1773 loaded; the bootstrap command in "DBD::Driver::dr::driver()" triggers
1774 this, and the call is generated in the BOOT section of Driver.xst.
1775 These statements are needed to allow your driver to use the DBI macros.
1776 They will include your private header file dbdimp.h in turn. Note that
1777 DBISTATE_INIT requires the name of the argument to "dbd_init()" to be
1778 called "dbistate()".
1779 The dbd_drv_error method
1781 You need a function to record errors so DBI can access them properly.
1783 You can call it whatever you like, but we'll call it "dbd_drv_error()"
1784 here.
1785 The argument list depends on your database software; different systems
1787 provide different ways to get at error information.
1788 static void dbd_drv_error(SV *h, int rc, const char *what)
1790 {
1791 Note that h is a generic handle, may it be a driver handle, a database
1793 or a statement handle.
1794 D_imp_xxh(h);
1796 This macro will declare and initialize a variable imp_xxh with a
1798 pointer to your private handle pointer. You may cast this to to
1799 imp_drh_t, imp_dbh_t or imp_sth_t.
1800 To record the error correctly, equivalent to the "set_err()" method,
1802 use one of the "DBIh_SET_ERR_CHAR(...)" or "DBIh_SET_ERR_SV(...)"
1803 macros, which were added in DBI 1.41:
1804 DBIh_SET_ERR_SV(h, imp_xxh, err, errstr, state, method);
1806 DBIh_SET_ERR_CHAR(h, imp_xxh, err_c, err_i, errstr, state, method);
1807 For "DBIh_SET_ERR_SV" the err, errstr, state, and method parameters are
1809 "SV*".
1810 For "DBIh_SET_ERR_CHAR" the err_c, errstr, state, method parameters are
1812 "char*".
1813 The err_i parameter is an "IV" that's used instead of err_c if err_c is
1815 "Null".
1816 The method parameter can be ignored.
1818 The "DBIh_SET_ERR_CHAR" macro is usually the simplest to use when you
1820 just have an integer error code and an error message string:
1821 DBIh_SET_ERR_CHAR(h, imp_xxh, Nullch, rc, what, Nullch, Nullch);
1823 As you can see, any parameters that aren't relevant to you can be
1825 "Null".
1826 To make drivers compatible with DBI < 1.41 you should be using
1828 dbivport.h as described in "Driver.h" above.
1829 The (obsolete) macros such as "DBIh_EVENT2" should be removed from
1831 drivers.
1832 The names "dbis" and "DBIS", which were used in previous versions of
1834 this document, should be replaced with the "DBIc_STATE(imp_xxh)" macro.
1835 The name "DBILOGFP", which was also used in previous versions of this
1837 document, should be replaced by "DBIc_LOGPIO(imp_xxh)".
1838 Your code should not call the C "<stdio.h>" I/O functions; you should
1840 use "PerlIO_printf()" as shown:
1841 if (DBIc_TRACE_LEVEL(imp_xxh) >= 2)
1843 PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar %s: %s\n",
1844 foo, neatsvpv(errstr,0));
1845 That's the first time we see how tracing works within a DBI driver.
1847 Make use of this as often as you can, but don't output anything at a
1848 trace level less than 3. Levels 1 and 2 are reserved for the DBI.
1849 You can define up to 8 private trace flags using the top 8 bits of
1851 "DBIc_TRACE_FLAGS(imp)", that is: 0xFF000000. See the
1852 "parse_trace_flag()" method elsewhere in this document.
1853 The dbd_dr_data_sources method
1855 This method is optional; the support for it was added in DBI v1.33.
1857 As noted in the discussion of Driver.pm, if the data sources can be
1859 determined by pure Perl code, do it that way. If, as in DBD::Informix,
1860 the information is obtained by a C function call, then you need to
1861 define a function that matches the prototype:
1862 extern AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attrs);
1864 An outline implementation for DBD::Informix follows, assuming that the
1866 "sqgetdbs()" function call shown will return up to 100 databases names,
1867 with the pointers to each name in the array dbsname and the name
1868 strings themselves being stores in dbsarea.
1869 AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attr)
1871 {
1872 int ndbs;
1873 int i;
1874 char *dbsname[100];
1875 char dbsarea[10000];
1876 AV *av = Nullav;
1877 if (sqgetdbs(&ndbs, dbsname, 100, dbsarea, sizeof(dbsarea)) == 0)
1879 {
1880 av = NewAV();
1881 av_extend(av, (I32)ndbs);
1882 sv_2mortal((SV *)av);
1883 for (i = 0; i < ndbs; i++)
1884 av_store(av, i, newSVpvf("dbi:Informix:%s", dbsname[i]));
1885 }
1886 return(av);
1887 }
1888 The actual DBD::Informix implementation has a number of extra lines of
1890 code, logs function entry and exit, reports the error from
1891 "sqgetdbs()", and uses "#define"'d constants for the array sizes.
1892 The dbd_db_login6 method
1894 int dbd_db_login6_sv(SV* dbh, imp_dbh_t* imp_dbh, SV* dbname,
1896 SV* user, SV* auth, SV *attr);
1897 or
1899 int dbd_db_login6(SV* dbh, imp_dbh_t* imp_dbh, char* dbname,
1901 char* user, char* auth, SV *attr);
1902 This function will really connect to the database. The argument dbh is
1904 the database handle. imp_dbh is the pointer to the handles private
1905 data, as is imp_xxx in "dbd_drv_error()" above. The arguments dbname,
1906 user, auth and attr correspond to the arguments of the driver handle's
1907 "connect()" method.
1908 You will quite often use database specific attributes here, that are
1910 specified in the DSN. I recommend you parse the DSN (using Perl) within
1911 the "connect()" method and pass the segments of the DSN via the
1912 attributes parameter through "_login()" to "dbd_db_login6()".
1913 Here's how you fetch them; as an example we use hostname attribute,
1915 which can be up to 12 characters long excluding null terminator:
1916 SV** svp;
1918 STRLEN len;
1919 char* hostname;
1920 if ( (svp = DBD_ATTRIB_GET_SVP(attr, "drv_hostname", 12)) && SvTRUE(*svp)) {
1922 hostname = SvPV(*svp, len);
1923 DBD_ATTRIB_DELETE(attr, "drv_hostname", 12); /* avoid later STORE */
1924 } else {
1925 hostname = "localhost";
1926 }
1927 If you handle any driver specific attributes in the dbd_db_login6
1929 method you probably want to delete them from "attr" (as above with
1930 DBD_ATTRIB_DELETE). If you don't delete your handled attributes DBI
1931 will call "STORE" for each attribute after the connect/login and this
1932 is at best redundant for attributes you have already processed.
1933 Note: Until revision 11605 (post DBI 1.607), there was a problem with
1935 DBD_ATTRIBUTE_DELETE so unless you require a DBI version after 1.607
1936 you need to replace each DBD_ATTRIBUTE_DELETE call with:
1937 hv_delete((HV*)SvRV(attr), key, key_len, G_DISCARD)
1939 Note that you can also obtain standard attributes such as AutoCommit
1941 and ChopBlanks from the attributes parameter, using "DBD_ATTRIB_GET_IV"
1942 for integer attributes.
1943 If, for example, your database does not support transactions but
1945 AutoCommit is set off (requesting transaction support), then you can
1946 emulate a 'failure to connect'.
1947 Now you should really connect to the database. In general, if the
1949 connection fails, it is best to ensure that all allocated resources are
1950 released so that the handle does not need to be destroyed separately.
1951 If you are successful (and possibly even if you fail but you have
1952 allocated some resources), you should use the following macros:
1953 DBIc_IMPSET_on(imp_dbh);
1955 This indicates that the driver (implementor) has allocated resources in
1957 the imp_dbh structure and that the implementors private
1958 "dbd_db_destroy()" function should be called when the handle is
1959 destroyed.
1960 DBIc_ACTIVE_on(imp_dbh);
1962 This indicates that the handle has an active connection to the server
1964 and that the "dbd_db_disconnect()" function should be called before the
1965 handle is destroyed.
1966 Note that if you do need to fail, you should report errors via the drh
1968 or imp_drh rather than via dbh or imp_dbh because imp_dbh will be
1969 destroyed by the failure, so errors recorded in that handle will not be
1970 visible to DBI, and hence not the user either.
1971 Note too, that the function is passed dbh and imp_dbh, and there is a
1973 macro "D_imp_drh_from_dbh" which can recover the imp_drh from the
1974 imp_dbh. However, there is no DBI macro to provide you with the drh
1975 given either the imp_dbh or the dbh or the imp_drh (and there's no way
1976 to recover the dbh given just the imp_dbh).
1977 This suggests that, despite the above notes about "dbd_drv_error()"
1979 taking an "SV *", it may be better to have two error routines, one
1980 taking imp_dbh and one taking imp_drh instead. With care, you can
1981 factor most of the formatting code out so that these are small routines
1982 calling a common error formatter. See the code in DBD::Informix 1.05.00
1983 for more information.
1984 The "dbd_db_login6()" function should return TRUE for success, FALSE
1986 otherwise.
1987 Drivers implemented long ago may define the five-argument function
1989 "dbd_db_login()" instead of "dbd_db_login6()". The missing argument is
1990 the attributes. There are ways to work around the missing attributes,
1991 but they are ungainly; it is much better to use the 6-argument form.
1992 Even later drivers will use "dbd_db_login6_sv()" which provides the
1993 dbname, username and password as SVs.
1994 The dbd_db_commit and dbd_db_rollback methods
1996 int dbd_db_commit(SV *dbh, imp_dbh_t *imp_dbh);
1998 int dbd_db_rollback(SV* dbh, imp_dbh_t* imp_dbh);
1999 These are used for commit and rollback. They should return TRUE for
2001 success, FALSE for error.
2002 The arguments dbh and imp_dbh are the same as for "dbd_db_login6()"
2004 above; I will omit describing them in what follows, as they appear
2005 always.
2006 These functions should return TRUE for success, FALSE otherwise.
2008 The dbd_db_disconnect method
2010 This is your private part of the "disconnect()" method. Any dbh with
2012 the ACTIVE flag on must be disconnected. (Note that you have to set it
2013 in "dbd_db_connect()" above.)
2014 int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);
2016 The database handle will return TRUE for success, FALSE otherwise. In
2018 any case it should do a:
2019 DBIc_ACTIVE_off(imp_dbh);
2021 before returning so DBI knows that "dbd_db_disconnect()" was executed.
2023 Note that there's nothing to stop a dbh being disconnected while it
2025 still have active children. If your database API reacts badly to trying
2026 to use an sth in this situation then you'll need to add code like this
2027 to all sth methods:
2028 if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth)))
2030 return 0;
2031 Alternatively, you can add code to your driver to keep explicit track
2033 of the statement handles that exist for each database handle and
2034 arrange to destroy those handles before disconnecting from the
2035 database. There is code to do this in DBD::Informix. Similar comments
2036 apply to the driver handle keeping track of all the database handles.
2037 Note that the code which destroys the subordinate handles should only
2039 release the associated database resources and mark the handles
2040 inactive; it does not attempt to free the actual handle structures.
2041 This function should return TRUE for success, FALSE otherwise, but it
2043 is not clear what anything can do about a failure.
2044 The dbd_db_discon_all method
2046 int dbd_discon_all (SV *drh, imp_drh_t *imp_drh);
2048 This function may be called at shutdown time. It should make best-
2050 efforts to disconnect all database handles - if possible. Some
2051 databases don't support that, in which case you can do nothing but
2052 return 'success'.
2053 This function should return TRUE for success, FALSE otherwise, but it
2055 is not clear what anything can do about a failure.
2056 The dbd_db_destroy method
2058 This is your private part of the database handle destructor. Any dbh
2060 with the IMPSET flag on must be destroyed, so that you can safely free
2061 resources. (Note that you have to set it in "dbd_db_connect()" above.)
2062 void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh)
2064 {
2065 DBIc_IMPSET_off(imp_dbh);
2066 }
2067 The DBI Driver.xst code will have called "dbd_db_disconnect()" for you,
2069 if the handle is still 'active', before calling "dbd_db_destroy()".
2070 Before returning the function must switch IMPSET to off, so DBI knows
2072 that the destructor was called.
2073 A DBI handle doesn't keep references to its children. But children do
2075 keep references to their parents. So a database handle won't be
2076 "DESTROY"'d until all its children have been "DESTROY"'d.
2077 The dbd_db_STORE_attrib method
2079 This function handles
2081 $dbh->{$key} = $value;
2083 Its prototype is:
2085 int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
2087 SV* valuesv);
2088 You do not handle all attributes; on the contrary, you should not
2090 handle DBI attributes here: leave this to DBI. (There are two
2091 exceptions, AutoCommit and ChopBlanks, which you should care about.)
2092 The return value is TRUE if you have handled the attribute or FALSE
2094 otherwise. If you are handling an attribute and something fails, you
2095 should call "dbd_drv_error()", so DBI can raise exceptions, if desired.
2096 If "dbd_drv_error()" returns, however, you have a problem: the user
2097 will never know about the error, because he typically will not check
2098 "$dbh->errstr()".
2099 I cannot recommend a general way of going on, if "dbd_drv_error()"
2101 returns, but there are examples where even the DBI specification
2102 expects that you "croak()". (See the AutoCommit method in DBI.)
2103 If you have to store attributes, you should either use your private
2105 data structure imp_xxx, the handle hash (via "(HV*)SvRV(dbh)"), or use
2106 the private imp_data.
2107 The first is best for internal C values like integers or pointers and
2109 where speed is important within the driver. The handle hash is best for
2110 values the user may want to get/set via driver-specific attributes.
2111 The private imp_data is an additional "SV" attached to the handle. You
2112 could think of it as an unnamed handle attribute. It's not normally
2113 used.
2114 The dbd_db_FETCH_attrib method
2116 This is the counterpart of "dbd_db_STORE_attrib()", needed for:
2118 $value = $dbh->{$key};
2120 Its prototype is:
2122 SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv);
2124 Unlike all previous methods this returns an "SV" with the value. Note
2126 that you should normally execute "sv_2mortal()", if you return a
2127 nonconstant value. (Constant values are &sv_undef, &sv_no and &sv_yes.)
2128 Note, that DBI implements a caching algorithm for attribute values. If
2130 you think, that an attribute may be fetched, you store it in the dbh
2131 itself:
2132 if (cacheit) /* cache value for later DBI 'quick' fetch? */
2134 hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);
2135 The dbd_st_prepare method
2137 This is the private part of the "prepare()" method. Note that you must
2139 not really execute the statement here. You may, however, preparse and
2140 validate the statement, or do similar things.
2141 int dbd_st_prepare(SV* sth, imp_sth_t* imp_sth, char* statement,
2143 SV* attribs);
2144 A typical, simple, possibility is to do nothing and rely on the perl
2146 "prepare()" code that set the Statement attribute on the handle. This
2147 attribute can then be used by "dbd_st_execute()".
2148 If the driver supports placeholders then the NUM_OF_PARAMS attribute
2150 must be set correctly by "dbd_st_prepare()":
2151 DBIc_NUM_PARAMS(imp_sth) = ...
2153 If you can, you should also setup attributes like NUM_OF_FIELDS, NAME,
2155 etc. here, but DBI doesn't require that - they can be deferred until
2156 execute() is called. However, if you do, document it.
2157 In any case you should set the IMPSET flag, as you did in
2159 "dbd_db_connect()" above:
2160 DBIc_IMPSET_on(imp_sth);
2162 The dbd_st_execute method
2164 This is where a statement will really be executed.
2166 int dbd_st_execute(SV* sth, imp_sth_t* imp_sth);
2168 Note that you must be aware a statement may be executed repeatedly.
2170 Also, you should not expect that "finish()" will be called between two
2171 executions, so you might need code, like the following, near the start
2172 of the function:
2173 if (DBIc_ACTIVE(imp_sth))
2175 dbd_st_finish(h, imp_sth);
2176 If your driver supports the binding of parameters (it should!), but the
2178 database doesn't, you must do it here. This can be done as follows:
2179 SV *svp;
2181 char* statement = DBD_ATTRIB_GET_PV(h, "Statement", 9, svp, "");
2182 int numParam = DBIc_NUM_PARAMS(imp_sth);
2183 int i;
2184 for (i = 0; i < numParam; i++)
2186 {
2187 char* value = dbd_db_get_param(sth, imp_sth, i);
2188 /* It is your drivers task to implement dbd_db_get_param, */
2189 /* it must be setup as a counterpart of dbd_bind_ph. */
2190 /* Look for '?' and replace it with 'value'. Difficult */
2191 /* task, note that you may have question marks inside */
2192 /* quotes and comments the like ... :-( */
2193 /* See DBD::mysql for an example. (Don't look too deep into */
2194 /* the example, you will notice where I was lazy ...) */
2195 }
2196 The next thing is to really execute the statement.
2198 Note that you must set the attributes NUM_OF_FIELDS, NAME, etc when the
2200 statement is successfully executed if the driver has not already done
2201 so: they may be used even before a potential "fetchrow()". In
2202 particular you have to tell DBI the number of fields that the statement
2203 has, because it will be used by DBI internally. Thus the function will
2204 typically ends with:
2205 if (isSelectStatement) {
2207 DBIc_NUM_FIELDS(imp_sth) = numFields;
2208 DBIc_ACTIVE_on(imp_sth);
2209 }
2210 It is important that the ACTIVE flag only be set for "SELECT"
2212 statements (or any other statements that can return many values from
2213 the database using a cursor-like mechanism). See "dbd_db_connect()"
2214 above for more explanations.
2215 There plans for a preparse function to be provided by DBI, but this has
2217 not reached fruition yet. Meantime, if you want to know how ugly it
2218 can get, try looking at the "dbd_ix_preparse()" in DBD::Informix
2219 dbdimp.ec and the related functions in iustoken.c and sqltoken.c.
2220 The dbd_st_fetch method
2222 This function fetches a row of data. The row is stored in in an array,
2224 of "SV"'s that DBI prepares for you. This has two advantages: it is
2225 fast (you even reuse the "SV"'s, so they don't have to be created after
2226 the first "fetchrow()"), and it guarantees that DBI handles
2227 "bind_cols()" for you.
2228 What you do is the following:
2230 AV* av;
2232 int numFields = DBIc_NUM_FIELDS(imp_sth); /* Correct, if NUM_FIELDS
2233 is constant for this statement. There are drivers where this is
2234 not the case! */
2235 int chopBlanks = DBIc_is(imp_sth, DBIcf_ChopBlanks);
2236 int i;
2237 if (!fetch_new_row_of_data(...)) {
2239 ... /* check for error or end-of-data */
2240 DBIc_ACTIVE_off(imp_sth); /* turn off Active flag automatically */
2241 return Nullav;
2242 }
2243 /* get the fbav (field buffer array value) for this row */
2244 /* it is very important to only call this after you know */
2245 /* that you have a row of data to return. */
2246 av = DBIc_DBISTATE(imp_sth)->get_fbav(imp_sth);
2247 for (i = 0; i < numFields; i++) {
2248 SV* sv = fetch_a_field(..., i);
2249 if (chopBlanks && SvOK(sv) && type_is_blank_padded(field_type[i])) {
2250 /* Remove white space from end (only) of sv */
2251 }
2252 sv_setsv(AvARRAY(av)[i], sv); /* Note: (re)use! */
2253 }
2254 return av;
2255 There's no need to use a "fetch_a_field()" function returning an "SV*".
2257 It's more common to use your database API functions to fetch the data
2258 as character strings and use code like this:
2259 sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);
2261 "NULL" values must be returned as "undef". You can use code like this:
2263 SvOK_off(AvARRAY(av)[i]);
2265 The function returns the "AV" prepared by DBI for success or "Nullav"
2267 otherwise.
2268 *FIX ME* Discuss what happens when there's no more data to fetch.
2270 Are errors permitted if another fetch occurs after the first fetch
2271 that reports no more data. (Permitted, not required.)
2272 If an error occurs which leaves the $sth in a state where remaining
2274 rows can't be fetched then Active should be turned off before the
2275 method returns.
2276 The dbd_st_finish3 method
2278 The "$sth->finish()" method can be called if the user wishes to
2280 indicate that no more rows will be fetched even if the database has
2281 more rows to offer, and the DBI code can call the function when handles
2282 are being destroyed. See the DBI specification for more background
2283 details.
2284 In both circumstances, the DBI code ends up calling the
2286 "dbd_st_finish3()" method (if you provide a mapping for
2287 "dbd_st_finish3()" in dbdimp.h), or "dbd_st_finish()" otherwise. The
2288 difference is that "dbd_st_finish3()" takes a third argument which is
2289 an "int" with the value 1 if it is being called from a "destroy()"
2290 method and 0 otherwise.
2291 Note that DBI v1.32 and earlier test on "dbd_db_finish3()" to call
2293 "dbd_st_finish3()"; if you provide "dbd_st_finish3()", either define
2294 "dbd_db_finish3()" too, or insist on DBI v1.33 or later.
2295 All it needs to do is turn off the Active flag for the sth. It will
2297 only be called by Driver.xst code, if the driver has set ACTIVE to on
2298 for the sth.
2299 Outline example:
2301 int dbd_st_finish3(SV* sth, imp_sth_t* imp_sth, int from_destroy) {
2303 if (DBIc_ACTIVE(imp_sth))
2304 {
2305 /* close cursor or equivalent action */
2306 DBIc_ACTIVE_off(imp_sth);
2307 }
2308 return 1;
2309 }
2310 The from_destroy parameter is true if "dbd_st_finish3()" is being
2312 called from "DESTROY()" - and so the statement is about to be
2313 destroyed. For many drivers there is no point in doing anything more
2314 than turning off the Active flag in this case.
2315 The function returns TRUE for success, FALSE otherwise, but there isn't
2317 a lot anyone can do to recover if there is an error.
2318 The dbd_st_destroy method
2320 This function is the private part of the statement handle destructor.
2322 void dbd_st_destroy(SV* sth, imp_sth_t* imp_sth) {
2324 ... /* any clean-up that's needed */
2325 DBIc_IMPSET_off(imp_sth); /* let DBI know we've done it */
2326 }
2327 The DBI Driver.xst code will call "dbd_st_finish()" for you, if the sth
2329 has the ACTIVE flag set, before calling "dbd_st_destroy()".
2330 The dbd_st_STORE_attrib and dbd_st_FETCH_attrib methods
2332 These functions correspond to "dbd_db_STORE()" and "dbd_db_FETCH()"
2334 attrib above, except that they are for statement handles. See above.
2335 int dbd_st_STORE_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv,
2337 SV* valuesv);
2338 SV* dbd_st_FETCH_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv);
2339 The dbd_bind_ph method
2341 This function is internally used by the "bind_param()" method, the
2343 "bind_param_inout()" method and by the DBI Driver.xst code if
2344 "execute()" is called with any bind parameters.
2345 int dbd_bind_ph (SV *sth, imp_sth_t *imp_sth, SV *param,
2347 SV *value, IV sql_type, SV *attribs,
2348 int is_inout, IV maxlen);
2349 The param argument holds an "IV" with the parameter number (1, 2, ...).
2351 The value argument is the parameter value and sql_type is its type.
2352 If your driver does not support "bind_param_inout()" then you should
2354 ignore maxlen and croak if is_inout is TRUE.
2355 If your driver does support "bind_param_inout()" then you should note
2357 that value is the "SV" after dereferencing the reference passed to
2358 "bind_param_inout()".
2359 In drivers of simple databases the function will, for example, store
2361 the value in a parameter array and use it later in "dbd_st_execute()".
2362 See the DBD::mysql driver for an example.
2363 Implementing bind_param_inout support
2365 To provide support for parameters bound by reference rather than by
2367 value, the driver must do a number of things. First, and most
2368 importantly, it must note the references and stash them in its own
2369 driver structure. Secondly, when a value is bound to a column, the
2370 driver must discard any previous reference bound to the column. On
2371 each execute, the driver must evaluate the references and internally
2372 bind the values resulting from the references. This is only applicable
2373 if the user writes:
2374 $sth->execute;
2376 If the user writes:
2378 $sth->execute(@values);
2380 then DBI automatically calls the binding code for each element of
2382 @values. These calls are indistinguishable from explicit user calls to
2383 "bind_param()".
2384 C/XS version of Makefile.PL
2386 The Makefile.PL file for a C/XS driver is similar to the code needed
2387 for a pure Perl driver, but there are a number of extra bits of
2388 information needed by the build system.
2389 For example, the attributes list passed to "WriteMakefile()" needs to
2391 specify the object files that need to be compiled and built into the
2392 shared object (DLL). This is often, but not necessarily, just dbdimp.o
2393 (unless that should be dbdimp.obj because you're building on MS
2394 Windows).
2395 Note that you can reliably determine the extension of the object files
2397 from the $Config{obj_ext} values, and there are many other useful
2398 pieces of configuration information lurking in that hash. You get
2399 access to it with:
2400 use Config;
2402 Methods which do not need to be written
2404 The DBI code implements the majority of the methods which are accessed
2405 using the notation "DBI->function()", the only exceptions being
2406 "DBI->connect()" and "DBI->data_sources()" which require support from
2407 the driver.
2408 The DBI code implements the following documented driver, database and
2410 statement functions which do not need to be written by the DBD driver
2411 writer.
2412 $dbh->do()
2414 The default implementation of this function prepares, executes and
2415 destroys the statement. This can be replaced if there is a better
2416 way to implement this, such as "EXECUTE IMMEDIATE" which can
2417 sometimes be used if there are no parameters.
2418 $h->errstr()
2420 $h->err()
2421 $h->state()
2422 $h->trace()
2423 The DBD driver does not need to worry about these routines at all.
2424 $h->{ChopBlanks}
2426 This attribute needs to be honored during "fetch()" operations, but
2427 does not need to be handled by the attribute handling code.
2428 $h->{RaiseError}
2430 The DBD driver does not need to worry about this attribute at all.
2431 $h->{PrintError}
2433 The DBD driver does not need to worry about this attribute at all.
2434 $sth->bind_col()
2436 Assuming the driver uses the "DBIc_DBISTATE(imp_xxh)->get_fbav()"
2437 function (C drivers, see below), or the "$sth->_set_fbav($data)"
2438 method (Perl drivers) the driver does not need to do anything about
2439 this routine.
2440 $sth->bind_columns()
2442 Regardless of whether the driver uses
2443 "DBIc_DBISTATE(imp_xxh)->get_fbav()", the driver does not need to
2444 do anything about this routine as it simply iteratively calls
2445 "$sth->bind_col()".
2446 The DBI code implements a default implementation of the following
2448 functions which do not need to be written by the DBD driver writer
2449 unless the default implementation is incorrect for the Driver.
2450 $dbh->quote()
2452 This should only be written if the database does not accept the
2453 ANSI SQL standard for quoting strings, with the string enclosed in
2454 single quotes and any embedded single quotes replaced by two
2455 consecutive single quotes.
2456 For the two argument form of quote, you need to implement the
2458 "type_info()" method to provide the information that quote needs.
2459 $dbh->ping()
2461 This should be implemented as a simple efficient way to determine
2462 whether the connection to the database is still alive. Typically
2463 code like this:
2464 sub ping {
2466 my $dbh = shift;
2467 $sth = $dbh->prepare_cached(q{
2468 select * from A_TABLE_NAME where 1=0
2469 }) or return 0;
2470 $sth->execute or return 0;
2471 $sth->finish;
2472 return 1;
2473 }
2474 where A_TABLE_NAME is the name of a table that always exists (such
2476 as a database system catalogue).
2477
2479 The exposition above ignores the DBI MetaData methods. The metadata
2480 methods are all associated with a database handle.
2481 Using DBI::DBD::Metadata
2483 The DBI::DBD::Metadata module is a good semi-automatic way for the
2484 developer of a DBD module to write the "get_info()" and "type_info()"
2485 functions quickly and accurately.
2486 Generating the get_info method
2488 Prior to DBI v1.33, this existed as the method "write_getinfo_pm()" in
2490 the DBI::DBD module. From DBI v1.33, it exists as the method
2491 "write_getinfo_pm()" in the DBI::DBD::Metadata module. This discussion
2492 assumes you have DBI v1.33 or later.
2493 You examine the documentation for "write_getinfo_pm()" using:
2495 perldoc DBI::DBD::Metadata
2497 To use it, you need a Perl DBI driver for your database which
2499 implements the "get_info()" method. In practice, this means you need to
2500 install DBD::ODBC, an ODBC driver manager, and an ODBC driver for your
2501 database.
2502 With the pre-requisites in place, you might type:
2504 perl -MDBI::DBD::Metadata -we \
2506 "write_getinfo_pm (qw{ dbi:ODBC:foo_db username password Driver })"
2507 The procedure writes to standard output the code that should be added
2509 to your Driver.pm file and the code that should be written to
2510 lib/DBD/Driver/GetInfo.pm.
2511 You should review the output to ensure that it is sensible.
2513 Generating the type_info method
2515 Given the idea of the "write_getinfo_pm()" method, it was not hard to
2517 devise a parallel method, "write_typeinfo_pm()", which does the
2518 analogous job for the DBI "type_info_all()" metadata method. The
2519 "write_typeinfo_pm()" method was added to DBI v1.33.
2520 You examine the documentation for "write_typeinfo_pm()" using:
2522 perldoc DBI::DBD::Metadata
2524 The setup is exactly analogous to the mechanism described in
2526 "Generating the get_info method".
2527 With the pre-requisites in place, you might type:
2529 perl -MDBI::DBD::Metadata -we \
2531 "write_typeinfo (qw{ dbi:ODBC:foo_db username password Driver })"
2532 The procedure writes to standard output the code that should be added
2534 to your Driver.pm file and the code that should be written to
2535 lib/DBD/Driver/TypeInfo.pm.
2536 You should review the output to ensure that it is sensible.
2538 Writing DBD::Driver::db::get_info
2540 If you use the DBI::DBD::Metadata module, then the code you need is
2541 generated for you.
2542 If you decide not to use the DBI::DBD::Metadata module, you should
2544 probably borrow the code from a driver that has done so (eg
2545 DBD::Informix from version 1.05 onwards) and crib the code from there,
2546 or look at the code that generates that module and follow that. The
2547 method in Driver.pm will be very simple; the method in
2548 lib/DBD/Driver/GetInfo.pm is not very much more complex unless your
2549 DBMS itself is much more complex.
2550 Note that some of the DBI utility methods rely on information from the
2552 "get_info()" method to perform their operations correctly. See, for
2553 example, the "quote_identifier()" and quote methods, discussed below.
2554 Writing DBD::Driver::db::type_info_all
2556 If you use the "DBI::DBD::Metadata" module, then the code you need is
2557 generated for you.
2558 If you decide not to use the "DBI::DBD::Metadata" module, you should
2560 probably borrow the code from a driver that has done so (eg
2561 "DBD::Informix" from version 1.05 onwards) and crib the code from
2562 there, or look at the code that generates that module and follow that.
2563 The method in Driver.pm will be very simple; the method in
2564 lib/DBD/Driver/TypeInfo.pm is not very much more complex unless your
2565 DBMS itself is much more complex.
2566 Writing DBD::Driver::db::type_info
2568 The guidelines on writing this method are still not really clear. No
2569 sample implementation is available.
2570 Writing DBD::Driver::db::table_info
2572 *FIX ME* The guidelines on writing this method have not been written yet.
2573 No sample implementation is available.
2574 Writing DBD::Driver::db::column_info
2576 *FIX ME* The guidelines on writing this method have not been written yet.
2577 No sample implementation is available.
2578 Writing DBD::Driver::db::primary_key_info
2580 *FIX ME* The guidelines on writing this method have not been written yet.
2581 No sample implementation is available.
2582 Writing DBD::Driver::db::primary_key
2584 *FIX ME* The guidelines on writing this method have not been written yet.
2585 No sample implementation is available.
2586 Writing DBD::Driver::db::foreign_key_info
2588 *FIX ME* The guidelines on writing this method have not been written yet.
2589 No sample implementation is available.
2590 Writing DBD::Driver::db::tables
2592 This method generates an array of names in a format suitable for being
2593 embedded in SQL statements in places where a table name is expected.
2594 If your database hews close enough to the SQL standard or if you have
2596 implemented an appropriate "table_info()" function and and the
2597 appropriate "quote_identifier()" function, then the DBI default version
2598 of this method will work for your driver too.
2599 Otherwise, you have to write a function yourself, such as:
2601 sub tables
2603 {
2604 my($dbh, $cat, $sch, $tab, $typ) = @_;
2605 my(@res);
2606 my($sth) = $dbh->table_info($cat, $sch, $tab, $typ);
2607 my(@arr);
2608 while (@arr = $sth->fetchrow_array)
2609 {
2610 push @res, $dbh->quote_identifier($arr[0], $arr[1], $arr[2]);
2611 }
2612 return @res;
2613 }
2614 See also the default implementation in DBI.pm.
2616 Writing DBD::Driver::db::quote
2618 This method takes a value and converts it into a string suitable for
2619 embedding in an SQL statement as a string literal.
2620 If your DBMS accepts the SQL standard notation for strings (single
2622 quotes around the string as a whole with any embedded single quotes
2623 doubled up), then you do not need to write this method as DBI provides
2624 a default method that does it for you.
2625 If your DBMS uses an alternative notation or escape mechanism, then you
2627 need to provide an equivalent function. For example, suppose your DBMS
2628 used C notation with double quotes around the string and backslashes
2629 escaping both double quotes and backslashes themselves. Then you might
2630 write the function as:
2631 sub quote
2633 {
2634 my($dbh, $str) = @_;
2635 $str =~ s/["\\]/\\$&/gmo;
2636 return qq{"$str"};
2637 }
2638 Handling newlines and other control characters is left as an exercise
2640 for the reader.
2641 This sample method ignores the $data_type indicator which is the
2643 optional second argument to the method.
2644 Writing DBD::Driver::db::quote_identifier
2646 This method is called to ensure that the name of the given table (or
2647 other database object) can be embedded into an SQL statement without
2648 danger of misinterpretation. The result string should be usable in the
2649 text of an SQL statement as the identifier for a table.
2650 If your DBMS accepts the SQL standard notation for quoted identifiers
2652 (which uses double quotes around the identifier as a whole, with any
2653 embedded double quotes doubled up) and accepts "schema"."identifier"
2654 (and "catalog"."schema"."identifier" when a catalog is specified), then
2655 you do not need to write this method as DBI provides a default method
2656 that does it for you.
2657 In fact, even if your DBMS does not handle exactly that notation but
2659 you have implemented the "get_info()" method and it gives the correct
2660 responses, then it will work for you. If your database is fussier, then
2661 you need to implement your own version of the function.
2662 For example, DBD::Informix has to deal with an environment variable
2664 DELIMIDENT. If it is not set, then the DBMS treats names enclosed in
2665 double quotes as strings rather than names, which is usually a syntax
2666 error. Additionally, the catalog portion of the name is separated from
2667 the schema and table by a different delimiter (colon instead of dot),
2668 and the catalog portion is never enclosed in quotes. (Fortunately,
2669 valid strings for the catalog will never contain weird characters that
2670 might need to be escaped, unless you count dots, dashes, slashes and
2671 at-signs as weird.) Finally, an Informix database can contain objects
2672 that cannot be accessed because they were created by a user with the
2673 DELIMIDENT environment variable set, but the current user does not have
2674 it set. By design choice, the "quote_identifier()" method encloses
2675 those identifiers in double quotes anyway, which generally triggers a
2676 syntax error, and the metadata methods which generate lists of tables
2677 etc omit those identifiers from the result sets.
2678 sub quote_identifier
2680 {
2681 my($dbh, $cat, $sch, $obj) = @_;
2682 my($rv) = "";
2683 my($qq) = (defined $ENV{DELIMIDENT}) ? '"' : '';
2684 $rv .= qq{$cat:} if (defined $cat);
2685 if (defined $sch)
2686 {
2687 if ($sch !~ m/^\w+$/o)
2688 {
2689 $qq = '"';
2690 $sch =~ s/$qq/$qq$qq/gm;
2691 }
2692 $rv .= qq{$qq$sch$qq.};
2693 }
2694 if (defined $obj)
2695 {
2696 if ($obj !~ m/^\w+$/o)
2697 {
2698 $qq = '"';
2699 $obj =~ s/$qq/$qq$qq/gm;
2700 }
2701 $rv .= qq{$qq$obj$qq};
2702 }
2703 return $rv;
2704 }
2705 Handling newlines and other control characters is left as an exercise
2707 for the reader.
2708 Note that there is an optional fourth parameter to this function which
2710 is a reference to a hash of attributes; this sample implementation
2711 ignores that.
2712 This sample implementation also ignores the single-argument variant of
2714 the method.
2715
2717 Tracing in DBI is controlled with a combination of a trace level and a
2718 set of flags which together are known as the trace settings. The trace
2719 settings are stored in a single integer and divided into levels and
2720 flags by a set of masks ("DBIc_TRACE_LEVEL_MASK" and
2721 "DBIc_TRACE_FLAGS_MASK").
2722 Each handle has it's own trace settings and so does the DBI. When you
2724 call a method the DBI merges the handles settings into its own for the
2725 duration of the call: the trace flags of the handle are OR'd into the
2726 trace flags of the DBI, and if the handle has a higher trace level then
2727 the DBI trace level is raised to match it. The previous DBI trace
2728 setings are restored when the called method returns.
2729 Trace Level
2731 The trace level is the first 4 bits of the trace settings (masked by
2732 "DBIc_TRACE_FLAGS_MASK") and represents trace levels of 1 to 15. Do not
2733 output anything at trace levels less than 3 as they are reserved for
2734 DBI.
2735 For advice on what to output at each level see "Trace Levels" in DBI.
2737 To test for a trace level you can use the "DBIc_TRACE_LEVEL" macro like
2739 this:
2740 if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) {
2742 PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar");
2743 }
2744 Also note the use of PerlIO_printf which you should always use for
2746 tracing and never the C "stdio.h" I/O functions.
2747 Trace Flags
2749 Trace flags are used to enable tracing of specific activities within
2750 the DBI and drivers. The DBI defines some trace flags and drivers can
2751 define others. DBI trace flag names begin with a capital letter and
2752 driver specific names begin with a lowercase letter. For a list of DBI
2753 defined trace flags see "Trace Flags" in DBI.
2754 If you want to use private trace flags you'll probably want to be able
2756 to set them by name. Drivers are expected to override the
2757 parse_trace_flag (note the singular) and check if $trace_flag_name is a
2758 driver specific trace flags and, if not, then call the DBIs default
2759 parse_trace_flag(). To do that you'll need to define a
2760 parse_trace_flag() method like this:
2761 sub parse_trace_flag {
2763 my ($h, $name) = @_;
2764 return 0x01000000 if $name eq 'foo';
2765 return 0x02000000 if $name eq 'bar';
2766 return 0x04000000 if $name eq 'baz';
2767 return 0x08000000 if $name eq 'boo';
2768 return 0x10000000 if $name eq 'bop';
2769 return $h->SUPER::parse_trace_flag($name);
2770 }
2771 All private flag names must be lowercase, and all private flags must be
2773 in the top 8 of the 32 bits of "DBIc_TRACE_FLAGS(imp)" i.e.,
2774 0xFF000000.
2775 If you've defined a parse_trace_flag() method in ::db you'll also want
2777 it in ::st, so just alias it in:
2778 *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;
2780 You may want to act on the current 'SQL' trace flag that DBI defines to
2782 output SQL prepared/executed as DBI currently does not do SQL tracing.
2783 Trace Macros
2785 Access to the trace level and trace flags is via a set of macros.
2786 DBIc_TRACE_SETTINGS(imp) returns the trace settings
2788 DBIc_TRACE_LEVEL(imp) returns the trace level
2789 DBIc_TRACE_FLAGS(imp) returns the trace flags
2790 DBIc_TRACE(imp, flags, flaglevel, level)
2791 e.g.,
2793 DBIc_TRACE(imp, 0, 0, 4)
2795 if level >= 4
2796 DBIc_TRACE(imp, DBDtf_FOO, 2, 4)
2798 if tracing DBDtf_FOO & level>=2 or level>=4
2799 DBIc_TRACE(imp, DBDtf_FOO, 2, 0)
2801 as above but never trace just due to level
2802
2804 Study Oraperl.pm (supplied with DBD::Oracle) and Ingperl.pm (supplied
2805 with DBD::Ingres) and the corresponding dbdimp.c files for ideas.
2806 Note that the emulation code sets "$dbh->{CompatMode} = 1;" for each
2808 connection so that the internals of the driver can implement behaviour
2809 compatible with the old interface when dealing with those handles.
2810 Setting emulation perl variables
2812 For example, ingperl has a $sql_rowcount variable. Rather than try to
2813 manually update this in Ingperl.pm it can be done faster in C code. In
2814 "dbd_init()":
2815 sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);
2817 In the relevant places do:
2819 if (DBIc_COMPAT(imp_sth)) /* only do this for compatibility mode handles */
2821 sv_setiv(sql_rowcount, the_row_count);
2822
2824 The imp_xyz_t types
2825 Any handle has a corresponding C structure filled with private data.
2826 Some of this data is reserved for use by DBI (except for using the DBIc
2827 macros below), some is for you. See the description of the dbdimp.h
2828 file above for examples. Most functions in dbdimp.c are passed both the
2829 handle "xyz" and a pointer to "imp_xyz". In rare cases, however, you
2830 may use the following macros:
2831 D_imp_dbh(dbh)
2833 Given a function argument dbh, declare a variable imp_dbh and
2834 initialize it with a pointer to the handles private data. Note:
2835 This must be a part of the function header, because it declares a
2836 variable.
2837 D_imp_sth(sth)
2839 Likewise for statement handles.
2840 D_imp_xxx(h)
2842 Given any handle, declare a variable imp_xxx and initialize it with
2843 a pointer to the handles private data. It is safe, for example, to
2844 cast imp_xxx to "imp_dbh_t*", if "DBIc_TYPE(imp_xxx) == DBIt_DB".
2845 (You can also call "sv_derived_from(h, "DBI::db")", but that's much
2846 slower.)
2847 D_imp_dbh_from_sth
2849 Given a imp_sth, declare a variable imp_dbh and initialize it with
2850 a pointer to the parent database handle's implementors structure.
2851 Using DBIc_IMPSET_on
2853 The driver code which initializes a handle should use
2854 "DBIc_IMPSET_on()" as soon as its state is such that the cleanup code
2855 must be called. When this happens is determined by your driver code.
2856 Failure to call this can lead to corruption of data structures.
2858 For example, DBD::Informix maintains a linked list of database handles
2860 in the driver, and within each handle, a linked list of statements.
2861 Once a statement is added to the linked list, it is crucial that it is
2862 cleaned up (removed from the list). When DBIc_IMPSET_on() was being
2863 called too late, it was able to cause all sorts of problems.
2864 Using DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off()
2866 Once upon a long time ago, the only way of handling the internal DBI
2867 boolean flags/attributes was through macros such as:
2868 DBIc_WARN DBIc_WARN_on DBIc_WARN_off
2870 DBIc_COMPAT DBIc_COMPAT_on DBIc_COMPAT_off
2871 Each of these took an imp_xxh pointer as an argument.
2873 Since then, new attributes have been added such as ChopBlanks,
2875 RaiseError and PrintError, and these do not have the full set of
2876 macros. The approved method for handling these is now the four macros:
2877 DBIc_is(imp, flag)
2879 DBIc_has(imp, flag) an alias for DBIc_is
2880 DBIc_on(imp, flag)
2881 DBIc_off(imp, flag)
2882 DBIc_set(imp, flag, on) set if on is true, else clear
2883 Consequently, the "DBIc_XXXXX" family of macros is now mostly
2885 deprecated and new drivers should avoid using them, even though the
2886 older drivers will probably continue to do so for quite a while yet.
2887 However...
2888 There is an important exception to that. The ACTIVE and IMPSET flags
2890 should be set via the "DBIc_ACTIVE_on()" and "DBIc_IMPSET_on()" macros,
2891 and unset via the "DBIc_ACTIVE_off()" and "DBIc_IMPSET_off()" macros.
2892 Using the get_fbav() method
2894 THIS IS CRITICAL for C/XS drivers.
2895 The "$sth->bind_col()" and "$sth->bind_columns()" documented in the DBI
2897 specification do not have to be implemented by the driver writer
2898 because DBI takes care of the details for you.
2899 However, the key to ensuring that bound columns work is to call the
2901 function "DBIc_DBISTATE(imp_xxh)->get_fbav()" in the code which fetches
2902 a row of data.
2903 This returns an "AV", and each element of the "AV" contains the "SV"
2905 which should be set to contain the returned data.
2906 The pure Perl equivalent is the "$sth->_set_fbav($data)" method, as
2908 described in the part on pure Perl drivers.
2909
2911 This is definitely an open subject. It can be done, as demonstrated by
2912 the DBD::File driver, but it is not as simple as one might think.
2913 (Note that this topic is different from subclassing the DBI. For an
2915 example of that, see the t/subclass.t file supplied with the DBI.)
2916 The main problem is that the dbh's and sth's that your "connect()" and
2918 "prepare()" methods return are not instances of your DBD::Driver::db or
2919 DBD::Driver::st packages, they are not even derived from it. Instead
2920 they are instances of the DBI::db or DBI::st classes or a derived
2921 subclass. Thus, if you write a method "mymethod()" and do a
2922 $dbh->mymethod()
2924 then the autoloader will search for that method in the package DBI::db.
2926 Of course you can instead to a
2927 $dbh->func('mymethod')
2929 and that will indeed work, even if "mymethod()" is inherited, but not
2931 without additional work. Setting @ISA is not sufficient.
2932 Overwriting methods
2934 The first problem is, that the "connect()" method has no idea of
2935 subclasses. For example, you cannot implement base class and subclass
2936 in the same file: The "install_driver()" method wants to do a
2937 require DBD::Driver;
2939 In particular, your subclass has to be a separate driver, from the view
2941 of DBI, and you cannot share driver handles.
2942 Of course that's not much of a problem. You should even be able to
2944 inherit the base classes "connect()" method. But you cannot simply
2945 overwrite the method, unless you do something like this, quoted from
2946 DBD::CSV:
2947 sub connect ($$;$$$) {
2949 my ($drh, $dbname, $user, $auth, $attr) = @_;
2950 my $this = $drh->DBD::File::dr::connect($dbname, $user, $auth, $attr);
2952 if (!exists($this->{csv_tables})) {
2953 $this->{csv_tables} = {};
2954 }
2955 $this;
2957 }
2958 Note that we cannot do a
2960 $drh->SUPER::connect($dbname, $user, $auth, $attr);
2962 as we would usually do in a an OO environment, because $drh is an
2964 instance of DBI::dr. And note, that the "connect()" method of DBD::File
2965 is able to handle subclass attributes. See the description of Pure Perl
2966 drivers above.
2967 It is essential that you always call superclass method in the above
2969 manner. However, that should do.
2970 Attribute handling
2972 Fortunately the DBI specifications allow a simple, but still performant
2973 way of handling attributes. The idea is based on the convention that
2974 any driver uses a prefix driver_ for its private methods. Thus it's
2975 always clear whether to pass attributes to the super class or not. For
2976 example, consider this "STORE()" method from the DBD::CSV class:
2977 sub STORE {
2979 my ($dbh, $attr, $val) = @_;
2980 if ($attr !~ /^driver_/) {
2981 return $dbh->DBD::File::db::STORE($attr, $val);
2982 }
2983 if ($attr eq 'driver_foo') {
2984 ...
2985 }
2986
2988 Jonathan Leffler <jleffler@us.ibm.com> (previously
2989 <jleffler@informix.com>), Jochen Wiedmann <joe@ispsoft.de>, Steffen
2990 Goeldner <sgoeldner@cpan.org>, and Tim Bunce <dbi-users@perl.org>.
2991perl v5.10.1 2009-02-24 DBI::DBD(3)