dbd.html

perl教程

<p>The changes will occur both because the DBI specification is changing
and hence the requirements on DBD drivers change, and because feedback
from people reading this document will suggest improvements to it.</p>
<p>Please read the DBI documentation first and fully, including the DBI FAQ.
Then reread the DBI specification again as you're reading this. It'll help.</p>
<p>This document is a patchwork of contributions from various authors.
More contributions (preferably as patches) are very welcome.</p>
<p>
</p>
<hr />
<h1><a name="description">DESCRIPTION</a></h1>
<p>This document is primarily intended to help people writing new
database drivers for the Perl Database Interface (Perl DBI).
It may also help others interested in discovering why the internals of
a DBD driver are written the way they are.</p>
<p>This is a guide.  Few (if any) of the statements in it are completely
authoritative under all possible circumstances.  This means you will
need to use judgement in applying the guidelines in this document.
If in <em>any</em> doubt at all, please do contact the dbi-dev mailing list
(details given below) where Tim Bunce and other driver authors can help.</p>
<p>
</p>
<hr />
<h1><a name="creating_a_new_driver">CREATING A NEW DRIVER</a></h1>
<p>The first rule for creating a new database driver for the Perl DBI is
very simple: &quot;DON'T!&quot;</p>
<p>There is usually a driver already available for the database you want to
use, almost regardless of which database you choose.
And very often, the database will provide an ODBC driver interface, so
you can often use DBD::ODBC to access the database.
This is typically less convenient on a Unix box than on a Microsoft
Windows box, but there are numerous options for ODBC driver managers on
Unix too, and very often the ODBC driver is provided by the database
supplier.
Before deciding that you need to write a driver, do your homework to
ensure that you are not wasting your energies.</p>
<p>[As of December 2002, the consensus is that if you need an ODBC driver
manager on Unix, then the unixODBC driver (available from
<a href="http://www.unixodbc.org/">http://www.unixodbc.org/</a>) is the way to go.]</p>
<p>The second rule for creating a new database driver for the Perl DBI is
also very simple: &quot;Don't -- get someone else to do it for you!&quot;</p>
<p>Nevertheless, there are occasions when it is necessary to write a new
driver, often to use a proprietary language or API to access the
database more swiftly, or more comprehensively, than an ODBC driver can.
Then you should read this document very carefully, but with a suitably
sceptical eye.
If there is something in here that does not make any sense, question it.
You might be right that the information is bogus.
But don't come to that conclusion too quickly.</p>
<p>
</p>
<h2><a name="urls_and_mailing_lists">URLs and mailing lists</a></h2>
<p>The primary web-site for locating DBI software and information is</p>
<pre>
  <a href="http://dbi.perl.org/">http://dbi.perl.org/</a></pre>
<p>There are two main and one auxilliary mailing lists for people working
with DBI.  The primary lists are <a href="mailto:[e-mail]">[e-mail]</a> for general users
of DBI and DBD drivers, and <a href="mailto:[e-mail]">[e-mail]</a> mainly for DBD driver
writers (don't join the dbi-dev list unless you have a good reason).
The auxilliary list is <a href="mailto:[e-mail]">[e-mail]</a> for announcing new
releases of DBI or DBD drivers.</p>
<p>You can join these lists by accessing the web-site
<a href="http://dbi.perl.org/">http://dbi.perl.org/</a>.
The lists are closed so you cannot send email to any of the lists
unless you join the list first.</p>
<p>You should also consider monitoring the comp.lang.perl.* newsgroups,
especially comp.lang.perl.modules.</p>
<p>
</p>
<h2><a name="the_cheetah_book">The Cheetah book</a></h2>
<p>The definitive book on Perl DBI is the Cheetah book, so called because
of the picture on the cover.
Its proper title is 'Programming the Perl DBI: Database programming with
Perl' by Alligator Descartes and Tim Bunce, published by O'Reilly
Associates, February 2000, ISBN 1-56592-699-4.
Buy it now if you have not already done so, and read it.</p>
<p>
</p>
<h2><a name="locating_drivers">Locating drivers</a></h2>
<p>Before writing a new driver, it is in your interests to find out
whether there already is a driver for your database.  If there is such
a driver, it would be much easier to make use of it than to write your
own!</p>
<p>The primary web-site for locating Perl software is
<a href="http://search.cpan.org/">http://search.cpan.org/</a>.  You should look under the various
modules listings for the software you are after. For example:</p>
<pre>
  <a href="http://search.cpan.org/modlist/Database_Interfaces">http://search.cpan.org/modlist/Database_Interfaces</a></pre>
<p>Follow the DBD:: and DBIx:: links at the top to see those subsets.</p>
<p>See the DBI docs for information on DBI web sites and mailing lists.</p>
<p>
</p>
<h2><a name="registering_a_new_driver">Registering a new driver</a></h2>
<p>Before going through any official registration process, you will need
to establish that there is no driver already in the works.
You'll do that by asking the DBI mailing lists whether there is such a
driver available, or whether anybody is working on one.</p>
<p>When you get the go ahead, you will need to establish the name of the
driver and a prefix for the driver.
Typically, the name is based on the name of the database software it
uses, and the prefix is a contraction of that.
Hence, DBD::Oracle has the name Oracle and the prefix 'ora_'.
This information will be recorded in the DBI module.
Apart from documentation purposes, registration is a prerequisite for
<a href="../../lib/DBI/install_method.html">installing private methods</a>.</p>
<p>This document assumes you are writing a driver called DBD::Driver, and
that the prefix 'drv_' is assigned to the driver.</p>
<p>
</p>
<h2><a name="two_styles_of_database_driver">Two styles of database driver</a></h2>
<p>There are two distinct styles of database driver that can be written to
work with the Perl DBI.</p>
<p>Your driver can be written in pure Perl, requiring no C compiler.
When feasible, this is the best solution, but most databases are not
written in such a way that this can be done.
Some example pure Perl drivers are DBD::File and DBD::CSV.</p>
<p>Alternatively, and most commonly, your driver will need to use some C
code to gain access to the database.
This will be classified as a C/XS driver.</p>
<p>
</p>
<h2><a name="what_code_will_you_write">What code will you write?</a></h2>
<p>There are a number of files that need to be written for either a pure
Perl driver or a C/XS driver.
There are no extra files needed only by a pure Perl driver, but there are
several extra files needed only by a C/XS driver.</p>
<p>
</p>
<h3><a name="files_common_to_pure_perl_and_c_xs_drivers">Files common to pure Perl and C/XS drivers</a></h3>
<p>Assuming that your driver is called DBD::Driver, these files are:</p>
<ul>
<li><strong><a name="item_makefile_2epl">Makefile.PL</a></strong>

<li><strong><a name="item_readme">README</a></strong>

<li><strong><a name="item_manifest">MANIFEST</a></strong>

<li><strong><a name="item_driver_2epm">Driver.pm</a></strong>

<li><strong><a name="item_lib_2fbundle_2fdbd_2fdriver_2epm">lib/Bundle/DBD/Driver.pm</a></strong>

<li><strong><a name="item_lib_2fdbd_2fdriver_2fsummary_2epm">lib/DBD/Driver/Summary.pm</a></strong>

<li><strong><a name="item_t_2f_2a_2et">t/*.t</a></strong>

</ul>
<p>The first four files are mandatory.
Makefile.PL is used to control how the driver is built and installed.
The README file tells people who download the file about how to build
the module and any prerequisite software that must be installed.
The MANIFEST file is used by the standard Perl module distribution mechanism.
It lists all the source files that need to be distributed with your module.
Driver.pm is what is loaded by the DBI code; it contains the methods
peculiar to your driver.</p>
<p>The lib/Bundle/DBD/Driver.pm file allows you to specify other Perl
modules on which yours depends in a format that allows someone to type a
simple command and ensure that all the pre-requisites are in place as
well as building your driver.
The lib/DBD/Driver/Summary.pm file contains (an updated version of) the
information that was included - or that would have been included - in
the appendices of the Cheetah book as a summary of the abilities of your
driver and the associated database.</p>
<p>The files in the t subdirectory are unit tests for your driver.
You should write your tests as stringently as possible, while taking
into account the diversity of installations that you can encounter.
Your tests should not casually modify operational databases.
You should never damage existing tables in a database.
You should code your tests to use a constrained name space within the
database.
For example, the tables (and all other named objects) that are created
could all begin with 'dbd_drv_'.
At the end of a test run, there should be no testing objects left behind
in the database.
If you create any databases, you should remove them.
If your database supports temporary tables that are automatically
removed at the end of a session, then exploit them as often as possible.
Try to make your tests independent of each other.
If you have a test t/t11dowhat.t that depends upon the successful
running of t/t10thingamy.t, people cannot run the single test case
t/t11dowhat.t.
Further, running t/t11dowhat.t twice in a row is likely to fail (at
least, if t/t11dowhat.t modifies the database at all) because the
database at the start of the second run is not what you saw at the start
of the first run.
Document in your README file what you do, and what privileges people
need to do it.
You can, and probably should, sequence your tests by including a test
number before an abbreviated version of the test name; the tests are run
in the order in which the names are expanded by shell-style globbing.</p>
<p>Many drivers also install sub-modules DBD::Driver::SubModule for any of
a variety of different reasons, such as to support the metadata methods
(see the discussion of <a href="#metadata_methods">METADATA METHODS</a> below).
Such sub-modules are conventionally stored in the directory lib/DBD/Driver.
The module itself would usually be in a file SubModule.pm.
All such sub-modules should themselves be version stamped (see the
discussions far below).</p>
<p>
</p>
<h3><a name="extra_files_needed_by_c_xs_drivers">Extra files needed by C/XS drivers</a></h3>
<p>The software for a C/XS driver will typically contain at least four
extra files that are not relevant to a pure Perl driver.</p>
<ul>
<li><strong><a name="item_driver_2exs">Driver.xs</a></strong>

<li><strong><a name="item_driver_2eh">Driver.h</a></strong>

<li><strong><a name="item_dbdimp_2eh">dbdimp.h</a></strong>

<li><strong><a name="item_dbdimp_2ec">dbdimp.c</a></strong>

</ul>
<p>The Driver.xs file is used to generate C code that Perl can call to gain