名前¶

DBI::DBD - DBI データベースドライバ作成者ガイド

概要¶

  perldoc DBI::DBD

バージョンと変更可能性¶

このドキュメントは 未だに さらに作業を進めるために必要最小限のドラフトです。

DBI の仕様変更やその結果 DBD ドライバに要求されることが変更されること、 そしてこのドキュメントを読んだ人たちからフィードバックが改善を 提案することの二つの理由により変更が発生します。

まず DBI FAQを含めてすべての DBI ドキュメントをお読みください。 これを読むときには DBI 仕様を読み返します。 これは助けとなるでしょう。

このドキュメントは多くの作者からよせられた原稿を集めたものです。 さらなる寄稿(どちらかといえばパッチとして)は大歓迎です。

説明¶

このドキュメントは第一に Perl データベースインターフェース(Perl DBI)のための 新しいデータベースドライバを作成する人達を助けることを目指しています。 DBD ドライバの内部がどうしてそのように書かれているのかを理解したい 他の人たちにも助けになるでしょう。

これはガイドです。 すべての可能な環境下で完全に権威のある文は (もしあったとしても)あまりありません。 つまりこのドキュメントでのガイドラインを適用するときには判断が 必要になります。 もし 少しでも 疑問な点があれば、どうか Tim Bunce や他のドライバの作者が 助けてくれる dbi-dev メーリングリスト(詳細は以下にあります)に コンタクトしてください。

新しいドライバを作る¶

Perl DBI のための新しいデータベースドライバを作るための最初の規則は とても単純です: 作らない!

There is usually a driver already available for the database you want to use, almost regardless of which database you choose. 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. (TBT)

Before deciding that you need to write a driver, do your homework to ensure that you are not wasting your energies. (TBT)

[As of December 2002, the consensus is that if you need an ODBC driver manager on Unix, then the unixODBC driver (available from http://www.unixodbc.org/) is the way to go.] (TBT)

The second rule for creating a new database driver for the Perl DBI is also very simple: Don't -- get someone else to do it for you! (TBT)

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. (TBT)

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. (TBT)

URL とメーリングリスト¶

DBI ソフトウェアと情報が置いてある第一の WEB サイトは

  http://dbi.perl.org/

DBI で作業している人々のために主には二つ、そして補助的な一つの メーリングリストがあります。 主なリストは、DBI と DBD ドライバの一般的な利用者のための dbi-users@fugue.com、主に DBD ドライバの作者のための dbi-dev@fugue.comです(たいした理由も無く dbi-dev リストには 参加しないで下さい)。 補助的なリストは DBI または DBD ドライバの新しいリリースを アナウンスするための dbi-announce@fugue.com です。

これらのリストには Web サイト http://dbi.perl.org/ から 参加することができます。 そのリストは閉じているので、まずリストに参加しなければリストのメールを 送信することが出来ません。

また comp.lang.perl.* ニュースグループ、特に comp.lang.perl.modules を モニタすることも考慮してください。

チータ本¶

Perl DBI についての決定版はチータ本(表紙の絵からこう呼ばれます)です。 正しいタイトルは '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 です (訳注:和訳は「入門Perl DBI」ISBN 4873110505)。 まだ買っていなければ、今すぐ買いましょう。

ドライバの置き場所¶

新しいドライバを書く前に、あなたのデータベースのためのドライバが あるかどうかが気になるでしょう。 そのようなドライバがあれば、自分自身で作成するよりももっと簡単です!

Perl ソフトウェアを置いておくための一番の WEB サイトは http://search.cpan.org/ です。 たくさんのモジュールのリストがあります。 例えば:

  http://search.cpan.org/modlist/Database_Interfaces

これらのサブセットを見るために一番上の DBD:: と DBIx:: のリンクを 辿ってください。

情報については DBI Web サイトの DBI ドキュメントやメーリングリストを ご覧下さい。

新しいドライバを登録する¶

公式の登録処理を始める前に、すでに作業に入っているドライバが無いことを 確認する必要があります。 DBI メーリングリストに利用できるそのようなドライバがあるか、だれかが それについて作業していないかを尋ねることによって、確認することができます。

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_'. The prefix must be lowercase and contain no underscores other than the one at the end. (TBT)

This information will be recorded in the DBI module. Apart from documentation purposes, registration is a prerequisite for installing private methods. (TBT)

If you are writing a driver which will not be distributed on CPAN, then you should choose a prefix beginning with 'x_', to avoid potential prefix collisions with drivers registered in the future. Thus, if you wrote a non-CPAN distributed driver called DBD::CustomDB, the prefix might be 'x_cdb_'. (TBT)

This document assumes you are writing a driver called DBD::Driver, and that the prefix 'drv_' is assigned to the driver. (TBT)

2 種類のデータベースドライバ¶

Perl DBI と共に動作するために書かれるデータベースドライバには 二つの異なった種類があります。

ドライバを、C コンパイラを必要としないピュア Perl で書くことができます。 可能なら、これが最善の解法ですが、ほとんどのデータベースはこれが できるような方法で書かれていません。 ピュア Perl ドライバの例は DBD::File と DBD::CSV です。

もう一つの、そしてより一般的な方法として、ドライバは データベースへのアクセスを得るためにいくらかの C コードを使うことが必要です。 これは C/XS ドライバと分類されます。

書く必要のあるコードは?¶

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. (TBT)

Files common to pure Perl and C/XS drivers¶

Assuming that your driver is called DBD::Driver, these files are: (TBT)

• Makefile.PL

• META.yml

• README

• MANIFEST

• Driver.pm

• lib/Bundle/DBD/Driver.pm

• lib/DBD/Driver/Summary.pm

• t/*.t

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. (TBT)

Although the META.yml file is not required you are advised to create one. Of particular importance are the build_requires and configure_requires attributes which newer CPAN modules understand. You use these to tell the CPAN module (and CPANPLUS) that your build and configure mechanisms require DBI. The best reference for META.yml (at the time of writing) is http://module-build.sourceforge.net/META-spec-v1.4.html. You can find a reasonable example of a META.yml in DBD::ODBC. (TBT)

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. (TBT)

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. (TBT)

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: (TBT)

• Your tests should not casually modify operational databases.

  Your tests should not casually modify operational databases. (TBT)

• You should never damage existing tables in a database.

  You should never damage existing tables in a database. (TBT)

• 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_'.

  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_'. (TBT)

• At the end of a test run, there should be no testing objects left behind in the database.

  At the end of a test run, there should be no testing objects left behind in the database. (TBT)

• If you create any databases, you should remove them.

  If you create any databases, you should remove them. (TBT)

• If your database supports temporary tables that are automatically removed at the end of a session, then exploit them as often as possible.

  If your database supports temporary tables that are automatically removed at the end of a session, then exploit them as often as possible. (TBT)

• 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.

  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. (TBT)

• Document in your README file what you do, and what privileges people need to do it.

  Document in your README file what you do, and what privileges people need to do it. (TBT)

• 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.

  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. (TBT)

• It is in your interests to ensure that your tests work as widely as possible.

  It is in your interests to ensure that your tests work as widely as possible. (TBT)

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 "METADATA METHODS" 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). (TBT)

Extra files needed by C/XS drivers¶

The software for a C/XS driver will typically contain at least four extra files that are not relevant to a pure Perl driver. (TBT)

• Driver.xs

• Driver.h

• dbdimp.h

• dbdimp.c

The Driver.xs file is used to generate C code that Perl can call to gain access to the C functions you write that will, in turn, call down onto your database software. (TBT)

The Driver.h header is a stylized header that ensures you can access the necessary Perl and DBI macros, types, and function declarations. (TBT)

The dbdimp.h is used to specify which functions have been implemented by your driver. (TBT)

The dbdimp.c file is where you write the C code that does the real work of translating between Perl-ish data types and what the database expects to use and return. (TBT)

There are some (mainly small, but very important) differences between the contents of Makefile.PL and Driver.pm for pure Perl and C/XS drivers, so those files are described both in the section on creating a pure Perl driver and in the section on creating a C/XS driver. (TBT)

Obviously, you can add extra source code files to the list. (TBT)

ドライバとドライバ作者に必要なこと¶

To be remotely useful, your driver must be implemented in a format that allows it to be distributed via CPAN, the Comprehensive Perl Archive Network (http://www.cpan.org/ and http://search.cpan.org). Of course, it is easier if you do not have to meet this criterion, but you will not be able to ask for much help if you do not do so, and no-one is likely to want to install your module if they have to learn a new installation mechanism. (TBT)

ピュア Perl ドライバを作る¶

純粋な Perl ドライバを書くことは驚くほど簡単です。 しかし気をつけなければならない問題があります。 もちろん一番よい選択子は既にあるドライバをピックアップして、注意深く 一つ一つののメソッドを変更していくことです。

Also look carefully at DBD::AnyData and DBD::Template. (TBT)

例として DBD::File ドライバについて見ていきます; これはプレーンな ファイルをテーブルとしてアクセスするもので DBD::CSV の一部です。

最低限、実装しなければいけないファイルは Makefile.PL, README, MANIFEST, Driver.pm です。

ピュア Perl 版の Makefile.PL¶

まず通常は Makefile ジェネレータである Makefile.PL を書くことから 始めます。 このファイルの内容は ExtUtils::MakeMaker の man ページに詳しく 記述されています。 まずこれを読むことはとてもよいことです。 最低限 ExtUtils::MakeMaker man ページから CONFIGURE, DEFINED, PM, DIR, EXE_FILES, INC, LIBS, LINKTYPE, NAME, OPTIMIZE, PL_FILES, VERSION, VERSION_FROM, clean, depend, realclean 変数に ついて知っておいてください: これらはほとんどすべての Makefile.PL で使われます。

さらに Overriding MakeMaker Methods (MakeMaker メソッドの オーバーライド)の節や stcheck, disttest, dist ターゲットの説明についても 読んでください: それらは間違い無く有用です。

DBI ドライバにとって特に重要なのは ExtUtils::MM_Unix man ページでの postambleme メソッドです。

Eamcs ユーザには libscan メソッドをお勧めします; which removes これは Emacs バックアップファイル (ファイル名がチルダ '~' で終わるもの) を ファイル一覧から取り除きます。

さて例です; Driver という単語を使っているところにはあなたのドライバの 名前を入れてください:

  # -*- perl -*-

  use ExtUtils::MakeMaker;

  WriteMakefile(
      dbd_edit_mm_attribs( {
          'NAME'         => 'DBD::Driver',
          'VERSION_FROM' => 'Driver.pm',
          'INC'          => '',
          'dist'         => { 'SUFFIX'   => '.gz',
                              'COMPRESS' => 'gzip -9f' },
          'realclean'    => { FILES => '*.xsi' },
          'PREREQ_PM'    => '1.03',
          'CONFIGURE'    => sub {
              eval {require DBI::DBD;};
              if ($@) {
                  warn $@;
                  exit 0;
              }
              my $dbi_arch_dir = dbd_dbi_arch_dir();
              if (exists($opts{INC})) {
                  return {INC => "$opts{INC} -I$dbi_arch_dir"};
              } else {
                  return {INC => "-I$dbi_arch_dir"};
              }
          }
      },
      { create_pp_tests => 1})
  );

  package MY;
  sub postamble { return main::dbd_postamble(@_); }
  sub libscan {
      my ($self, $path) = @_;
      ($path =~ m/\~$/) ? undef : $path;
  }

Note the calls to dbd_edit_mm_attribs() and dbd_postamble(). (TBT)

The second hash reference in the call to dbd_edit_mm_attribs() (containing create_pp_tests()) is optional; you should not use it unless your driver is a pure Perl driver (that is, it does not use C and XS code). Therefore, the call to dbd_edit_mm_attribs() is not relevant for C/XS drivers and may be omitted; simply use the (single) hash reference containing NAME etc as the only argument to WriteMakefile(). (TBT)

Note that the dbd_edit_mm_attribs() code will fail if you do not have a t sub-directory containing at least one test case. (TBT)

PREREQ_PM tells MakeMaker that DBI (version 1.03 in this case) is required for this module. This will issue a warning that DBI 1.03 is missing if someone attempts to install your DBD without DBI 1.03. See CONFIGURE below for why this does not work reliably in stopping cpan testers failing your module if DBI is not installed. (TBT)

CONFIGURE is a subroutine called by MakeMaker during WriteMakefile. By putting the require DBI::DBD in this section we can attempt to load DBI::DBD but if it is missing we exit with success. As we exit successfully without creating a Makefile when DBI::DBD is missing cpan testers will not report a failure. This may seem at odds with PREREQ_PM but PREREQ_PM does not cause WriteMakefile to fail (unless you also specify PREREQ_FATAL which is strongly discouraged by MakeMaker) so WriteMakefile would continue to call dbd_dbi_arch_dir and fail. (TBT)

All drivers must use dbd_postamble() or risk running into problems. (TBT)

Note the specification of VERSION_FROM; the named file (Driver.pm) will be scanned for the first line that looks like an assignment to $VERSION, and the subsequent text will be used to determine the version number. Note the commentary in ExtUtils::MakeMaker on the subject of correctly formatted version numbers. (TBT)

If your driver depends upon external software (it usually will), you will need to add code to ensure that your environment is workable before the call to WriteMakefile(). If you need to check for the existence of an external library and perhaps modify INC to include the paths to where the external library header files are located and you cannot find the library or header files make sure you output a message saying they cannot be found but exit 0 (success) before calling WriteMakefile or CPAN testers will fail your module if the external library is not found. (TBT)

A full-fledged Makefile.PL can be quite large (for example, the files for DBD::Oracle and DBD::Informix are both over 1000 lines long, and the Informix one uses - and creates - auxiliary modules too). (TBT)

See also ExtUtils::MakeMaker and ExtUtils::MM_Unix. Consider using CPAN::MakeMaker in place of ExtUtils::MakeMaker. (TBT)

README¶

README ファイルは何のためのドライバか、ビルド処理のために事前に 必要なことは何か、実際のビルド処理、どうやって誰にエラーを報告するかについて 記述するべきです。

あなたの最悪の悪夢のなかですら思っても見なかったような方法で、利用者は ドライバのビルドやテスト処理を失敗させる方法を見つけます。 従って、このためこのドキュメントは守りを固めて、正確に、簡潔に書く 必要があります。

いつも通り、既にあるドライバの README を、あなたのものの基本として 使いましょう; DBD::Informix のものは、問題を回避するのに非常に成功しているので、 一見の価値があります。

• Note that users will have versions of Perl and DBI that are both older and newer than you expected, but this will seldom cause much trouble. When it does, it will be because you are using features of DBI that are not supported in the version they are using.

  Note that users will have versions of Perl and DBI that are both older and newer than you expected, but this will seldom cause much trouble. When it does, it will be because you are using features of DBI that are not supported in the version they are using. (TBT)

• Note that users will have versions of the database software that are both older and newer than you expected. You will save yourself time in the long run if you can identify the range of versions which have been tested and warn about versions which are not known to be OK.

  Note that users will have versions of the database software that are both older and newer than you expected. You will save yourself time in the long run if you can identify the range of versions which have been tested and warn about versions which are not known to be OK. (TBT)

• Note that many people trying to install your driver will not be experts in the database software.

  Note that many people trying to install your driver will not be experts in the database software. (TBT)

• Note that many people trying to install your driver will not be experts in C or Perl.

  Note that many people trying to install your driver will not be experts in C or Perl. (TBT)

MANIFEST¶

MANIFEST は Makefile の dist ターゲットによって、CPAN に アップロードされる配布 tar ファイルを構築するために使われます。 配布に含めたいすべてのファイルを 1 行ずつリストにします。

lib/Bundle/DBD/Driver.pm¶

CPAN モジュールは、あなたのドライバにあらかじめ必要なものを指定することを 可能とするとても強力なバンドル機構を提供します。

まずあらかじめ必要なものは Bundle::DBIです; あなたは他のものも 欲しかったり、必要だったりするかもしれません。 バンドル設定を正しく行えば、ユーザが以下のようにタイプすると:

        perl -MCPAN -e 'install Bundle::DBD::Driver'

Perl はあなたのドライバを構築するために必要とされるすべての Perl モジュールをダウンロード、コンパイル、テスト、 インストールしてくれます。

あらかじめ必要なモジュールは CONTENTS セクションに、公式の名前と ダッシュを付けて非公式な名前または説明を一覧にします。

• Listing Bundle::DBI as the main pre-requisite simplifies life.

  Bundle::DBI を主要なあらかじめ必要なものとしてリストに載せることは、 ものごとを簡単にさせます。

• Don't forget to list your driver.

  あなたのドライバをリストに載せるのを忘れないで下さい。

• Note that unless the DBMS is itself a Perl module, you cannot list it as a pre-requisite in this file.

  DBMS そのものは Perl モジュールでなければ、このファイルでのあらかじめ 必要なもののリストに載せることが出来ないことに注意してください。

• You should keep the version of the bundle the same as the version of your driver.

  バンドルのバージョンはあなたのドライバのバージョンと同じにするべきです。

• You should add configuration management, copyright, and licencing information at the top.

  構成管理、著作権、ライセンス情報をを加えたいかもしれません。

このファイルの適切な骨格を以下に示します。

  package Bundle::DBD::Driver;

  $VERSION = '0.01';

  1;

  __END__

  =head1 NAME

  Bundle::DBD::Driver - A bundle to install all DBD::Driver related modules

  =head1 SYNOPSIS

  C<perl -MCPAN -e 'install Bundle::DBD::Driver'>

  =head1 CONTENTS

  Bundle::DBI  - Bundle for DBI by TIMB (Tim Bunce)

  DBD::Driver  - DBD::Driver by YOU (Your Name)

  =head1 DESCRIPTION

  This bundle includes all the modules used by the Perl Database
  Interface (DBI) driver for Driver (DBD::Driver), assuming the
  use of DBI version 1.13 or later, created by Tim Bunce.

  If you've not previously used the CPAN module to install any
  bundles, you will be interrogated during its setup phase.
  But when you've done it once, it remembers what you told it.
  You could start by running:

    C<perl -MCPAN -e 'install Bundle::CPAN'>

  =head1 SEE ALSO

  Bundle::DBI

  =head1 AUTHOR

  Your Name E<lt>F<you@yourdomain.com>E<gt>

  =head1 THANKS

  This bundle was created by ripping off Bundle::libnet created by
  Graham Barr E<lt>F<gbarr@ti.com>E<gt>, and radically simplified
  with some information from Jochen Wiedmann E<lt>F<joe@ispsoft.de>E<gt>.
  The template was then included in the DBI::DBD documentation by
  Jonathan Leffler E<lt>F<jleffler@informix.com>E<gt>.

  =cut

lib/DBD/Driver/Summary.pm¶

There is no substitute for taking the summary file from a driver that was documented in the Perl book (such as DBD::Oracle or DBD::Informix or DBD::ODBC, to name but three), and adapting it to describe the facilities available via DBD::Driver when accessing the Driver database. (TBT)

ピュア Perl 版の Driver.pm¶

Driver.pm ファイルは Perl モジュール DBD::Driver をあなたの ドライバ用として定義します。 いくつかのバージョン情報、いくつかの変数定義、そして関数 driver() と ともに、標準よりも多くあるいは少ない構造を持つパッケージ DBD::Driver を 定義します。

It will also define three sub-packages of DBD::Driver: (TBT)

DBD::Driver::dr

with methods connect(), data_sources() and disconnect_all();

with methods connect(), data_sources() and disconnect_all(); (TBT)

DBD::Driver::db

with methods such as prepare();

with methods such as prepare(); (TBT)

DBD::Driver::st

with methods such as execute() and fetch().

with methods such as execute() and fetch(). (TBT)

Driver.pm ファイルには perldoc によって使われるフォーマットで DBD::Driver についての仕様のドキュメントも入れます。

In a pure Perl driver, the Driver.pm file is the core of the implementation. You will need to provide all the key methods needed by DBI. (TBT)

さあ例として File.pm の引用について詳しく見てみましょう。 どのモジュールにも共通となる(DBI 以外のモジュールでさえ)こと、あるいは 本当に DBD::File パッケージに特有のものについては無視します。

The DBD::Driver package¶

The header¶

  package DBD::File;

  use strict;
  use vars qw($VERSION $drh);

  $VERSION = "1.23.00"  # Version number of DBD::File

This is where the version number of your driver is specified, and is where Makefile.PL looks for this information. Please ensure that any other modules added with your driver are also version stamped so that CPAN does not get confused. (TBT)

It is recommended that you use a two-part (1.23) or three-part (1.23.45) version number. Also consider the CPAN system, which gets confused and considers version 1.10 to precede version 1.9, so that using a raw CVS, RCS or SCCS version number is probably not appropriate (despite being very common). (TBT)

For Subversion you could use: (TBT)

  $VERSION = sprintf("12.%06d", q$Revision$ =~ /(\d+)/o);

(use lots of leading zeros on the second portion so if you move the code to a shared repository like svn.perl.org the much larger revision numbers won't cause a problem, at least not for a few years). For RCS or CVS you can use: (TBT)

  $VERSION = sprintf "%d.%02d", '$Revision$ ' =~ /(\d+)\.(\d+)/;

which pads out the fractional part with leading zeros so all is well (so long as you don't go past x.99) (TBT)

  $drh = undef;         # holds driver handle once initialized

作成されたら、ここにドライバハンドルが格納されます。 ドライバにはたった一つのハンドルしかないと想定できるということに 注意してください。

The driver constructor¶

driver() メソッドがドライバハンドルのコンストラクタです。 DBD::Driver パッケージの driver() メソッドであって、 サブパッケージ DBD::Driver::dr, DBD::Driver::db, DBD::Driver::db のものではないことに注意してください。

  sub driver
  {
      return $drh if $drh;      # already created - return same one
      my ($class, $attr) = @_;

      $class .= "::dr";

      DBD::Driver::db->install_method('drv_example_dbh_method');
      DBD::Driver::st->install_method('drv_example_sth_method');

      # not a 'my' since we use it above to prevent multiple drivers
      $drh = DBI::_new_drh($class, {
              'Name'        => 'File',
              'Version'     => $VERSION,
              'Attribution' => 'DBD::File by Jochen Wiedmann',
          })
          or return undef;

      return $drh;
  }

DBI がどのようにそのハンドルを実装するかというよい例です。 ハンドルは３種類あります:ドライバハンドル(通常は $drh に 格納されます、以降 drh または $drh とします)、データベースハンドル (以降 dbh または $dbh とします)、そして 文ハンドル (以降 sth または $sth とします)です。

DBI::_new_drh() のプロトタイプは以下のようになります

  $drh = DBI::_new_drh($class, $public_attrs, $private_attrs);

以下の引数を取ります:

$class

is typically the class for your driver, (for example, "DBD::File::dr"), passed as the first argument to the driver() method.

通常ドライバのためのクラスになります; (たとえば "DBD::File::dr") が 最初の引数として driver() メソッドに渡されます。

$public_attrs

is a hash ref to attributes like Name, Version, and Attribution. These are processed and used by DBI. You had better not make any assumptions about them nor should you add private attributes here.

これは Name, Version, Attributrion といった属性の ハッシュリファレンスです。 これらは DBI によって処理され利用されます。 これらについて何か想定しないようがよいですし、ここに独自の属性を 追加してはいけません。

$private_attrs

This is another (optional) hash ref with your private attributes. DBI will store them and otherwise leave them alone.

これがもう一つの(オプションの)独自の属性を持ったハッシュリファレンスです。 DBI はこれを補完して、それ以外は手を出しません。

DBI::new_drh() メソッドと driver() メソッドは失敗すると両方とも undef を返します(この場合、ドライバハンドルがないので 失敗情報については $DBI::err と $DBI::errstr を見る必要があります)。

Using install_method() to expose driver-private methods¶

    DBD::Foo::db->install_method($method_name, \%attr);

Installs the driver-private method named by $method_name into the DBI method dispatcher so it can be called directly, avoiding the need to use the func() method. (TBT)

It is called as a static method on the driver class to which the method belongs. The method name must begin with the corresponding registered driver-private prefix. For example, for DBD::Oracle $method_name must being with 'ora_', and for DBD::AnyData it must begin with 'ad_'. (TBT)

The attributes can be used to provide fine control over how the DBI dispatcher handles the dispatching of the method. However, at this point, it's undocumented and very liable to change. (Volunteers to polish up and document the interface are very welcome to get in touch via dbi-dev@perl.org) (TBT)

Methods installed using install_method default to the standard error handling behaviour for DBI methods: clearing err and errstr before calling the method, and checking for errors to trigger RaiseError etc. on return. This differs from the default behaviour of func(). (TBT)

Note for driver authors: The DBD::Foo::xx->install_method call won't work until the class-hierarchy has been setup. Normally the DBI looks after that just after the driver is loaded. This means install_method() can't be called at the time the driver is loaded unless the class-hierarchy is set up first. The way to do that is to call the setup_driver() method: (TBT)

    DBI->setup_driver('DBD::Foo');

before using install_method(). (TBT)

The CLONE special subroutine¶

Also needed here, in the DBD::Driver package, is a CLONE() method that will be called by perl when an interpreter is cloned. All your CLONE() method needs to do, currently, is clear the cached $drh so the new interpreter won't start using the cached $drh from the old interpreter: (TBT)

  sub CLONE {
    undef $drh;
  }

See http://search.cpan.org/dist/perl/pod/perlmod.pod#Making_your_module_threadsafe for details. (TBT)

The DBD::Driver::dr package¶

次の行は以下のコードのようになります:

  package DBD::Driver::dr; # ====== DRIVER ======

  $DBD::Driver::dr::imp_data_size = 0;

ドライバがロードされるとき、DBI があなたに代わって面倒を見てくれるので、 ここや他の DBD::Driver::* のために @ISA が必要ないことに 注意してください。

 *FIX ME* Explain what the imp_data_size is, so that implementors aren't
 practicing cargo-cult programming.

The database handle constructor¶

データベースハンドルコンストラクタはドライバの (従って変更された 名前空間の) connect() メソッドです:

  sub connect
  {
      my ($drh, $dr_dsn, $user, $auth, $attr) = @_;

      # Some database specific verifications, default settings
      # and the like can go here. This should only include
      # syntax checks or similar stuff where it's legal to
      # 'die' in case of errors.
      # For example, many database packages requires specific
      # environment variables to be set; this could be where you
      # validate that they are set, or default them if they are not set.

      my $driver_prefix = "drv_"; # the assigned prefix for this driver

      # Process attributes from the DSN; we assume ODBC syntax
      # here, that is, the DSN looks like var1=val1;...;varN=valN
      foreach my $var ( split /;/, $dr_dsn ) {
          my ($attr_name, $attr_value) = split '=', $var, 2;
          return $drh->set_err($DBI::stderr, "Can't parse DSN part '$var'")
              unless defined $attr_value;

          # add driver prefix to attribute name if it doesn't have it already
          $attr_name = $driver_prefix.$attr_name
              unless $attr_name =~ /^$driver_prefix/o;

          # Store attribute into %$attr, replacing any existing value.
          # The DBI will STORE() these into $dbh after we've connected
          $attr->{$attr_name} = $attr_value;
      }

      # Get the attributes we'll use to connect.
      # We use delete here because these no need to STORE them
      my $db = delete $attr->{drv_database} || delete $attr->{drv_db}
          or return $drh->set_err($DBI::stderr, "No database name given in DSN '$dr_dsn'");
      my $host = delete $attr->{drv_host} || 'localhost';
      my $port = delete $attr->{drv_port} || 123456;

      # Assume you can attach to your database via drv_connect:
      my $connection = drv_connect($db, $host, $port, $user, $auth)
          or return $drh->set_err($DBI::stderr, "Can't connect to $dr_dsn: ...");

      # create a 'blank' dbh (call superclass constructor)
      my ($outer, $dbh) = DBI::_new_dbh($drh, { Name => $dr_dsn });

      $dbh->STORE('Active', 1 );
      $dbh->{drv_connection} = $connection;

      return $outer;
  }

これは上記の ドライバハンドルコンストラクタ とほとんど同じです。 属性は DBI マニュアルページに記述されています。

コンストラクタ DBI::_new_dbh() が呼ばれるとデータベースハンドルを返します。 コンストラクタのプロトタイプは以下の通りです:

  ($outer, $inner) = DBI::_new_dbh($drh, $public_attr, $private_attr);

$class が $drh に変わる以外は、ドライバハンドルコンストラクタ と 同じ引数を取ります。 Name 属性は DBI 標準属性です ("Database Handle Attributes" in DBI を参照してください)。

In scalar context, only the outer handle is returned. (TBT)

dbh 属性を設定するために STORE() メソッドを使うことに注意してください。 これはドライバコードでは、あなたが持っているハンドルオブジェクトは tieされたハッシュの「内部用('inner')」ハンドルであり、ドライバの利用者が 持っている「外部用(outer)」ハンドルではないためです。

内部用ハンドルを持っているので、ハッシュから値を取得したり、ハッシュに 設定するときtieの仕掛けは呼び出されません。 シンプルで特定でないドライバ特有の属性を取得したり、設定したいときに スピードの面からとても重宝します。

しかし DBI によって扱われる PrintError のようないくつかの属性値は、 ハッシュには実際には存在しません。 そして $h->FETCH($attrib) によって読みこまれ、 $h->STORE($attrib, $value) によって設定されなければなりません。 疑問があれば、これらのメソッドを使ってください。

The data_sources() method¶

The data_sources() method must populate and return a list of valid data sources, prefixed with the "dbi:Driver" incantation that allows them to be used in the first argument of the DBI->connect() method. An example of this might be scanning the $HOME/.odbcini file on Unix for ODBC data sources (DSNs). (TBT)

As a trivial example, consider a fixed list of data sources: (TBT)

  sub data_sources
  {
      my($drh, $attr) = @_;
      my(@list) = ();
      # You need more sophisticated code than this to set @list...
      push @list, "dbi:Driver:abc";
      push @list, "dbi:Driver:def";
      push @list, "dbi:Driver:ghi";
      # End of code to set @list
      return @list;
  }

The disconnect_all() method¶

If you need to release any resources when the driver is unloaded, you can provide a disconnect_all method. (TBT)

Other driver handle methods¶

If you need any other driver handle methods, they can follow here. (TBT)

Error handling¶

connectメソッドでなんらかの失敗があるというのはよくあることです。 例えば DBD::File では、f_dir 属性を使って存在しないディレクトリに カレントディレクトリを設定するとエラーとなります。

エラーを報告するためには、DBI::set_err メソッドを使います:

  $h->set_err($err, $errmsg, $state);

これはエラーが正しく記録されること、RaiseError や PrintError などが 正しく扱われることを保証します。

典型的には常にこのメソッドインスタンスを、いわゆるメソッドの最初の 引数として使います。

set_err は常に undef を返すので、エラーを扱うコードは通常、 以下のように単純にすることができます:

  return $h->set_err($err, $errmsg, $state) if ...;

The DBD::Driver::db package¶

  package DBD::Driver::db; # ====== DATABASE ======

  $DBD::Driver::db::imp_data_size = 0;

The statement handle constructor¶

文ハンドルコンストラクタでは新しいことはあまりありません; prepare() メソッドです:

  sub prepare
  {
      my ($dbh, $statement, @attribs) = @_;

      # create a 'blank' sth
      my ($outer, $sth) = DBI::_new_sth($dbh, { Statement => $statement });

      $sth->STORE('NUM_OF_PARAMS', ($statement =~ tr/?//));

      $sth->{drv_params} = [];

      return $outer;
  }

ここまではまだ同じです -- 引数をチェックし、上位クラスコンストラクタ DBI::_new_sth を呼び出します。 再び、スカラコンテキストでは、外側のハンドルのみが返されます。 このように Statement 属性はキャッシュされるべきです。

属性名での接頭辞 drv_ に注意してください:独自の属性はすべて小文字の そのような接頭辞を使わなければなりません。 この文書ですでに言及しているように、DBI は既知のドライバの接頭辞の レジストリを持っていて、登録されていない接頭辞を持つ 不明な属性について、将来警告するようになるかもしれません。

ここで属性 NUM_OF_PARAMS を設定するために文を解析することに 注意してください。 図示された方法は、信頼性があまりありません; SQL 分の一部としてクォートされた文字列、区切り文字、SQL コメントの中に 疑問符が現れると混乱する可能性があります。 DBI の仕様は明確に後に遅らせることを許しているので、 execute() メソッドで NUM_OF_PARAMS を設定することができますが、 しかしながら、その場合は bind_param() を呼び出すことが出来ません。

Transaction handling¶

ピュア Perl ドライバではほとんどトランザクションをサポートしていません。 このため commit() と rollback() メソッドは通常とても単純です:

  sub commit
  {
      my ($dbh) = @_;
      if ($dbh->FETCH('Warn')) {
          warn("Commit ineffective while AutoCommit is on");
      }
      0;
  }

  sub rollback {
      my ($dbh) = @_;
      if ($dbh->FETCH('Warn')) {
          warn("Rollback ineffective while AutoCommit is on");
      }
      0;
  }

Or even simpler, just use the default methods provided by the DBI that do nothing except return undef. (TBT)

The DBI's default begin_work() method can be used by inheritance. (TBT)

The STORE() and FETCH() methods¶

これらのメソッド(既に使っています。上記をご覧下さい)は、利用者が 以下のようにしたり:

  $dbh->{$attr} = $val;

またはこの反対にするときに使われます:

  $val = $dbh->{$attr};

なぜ tie されたハッシュリファレンスにはこれらのメソッドが必要なのかを 理解するための詳細については perltie をご覧下さい。

DBI は大抵の属性、特に RaiseError や PrintError といった属性を、 あなたに代わって取り扱います。 ドライバ独自の属性や DBI が扱うことが出来ない AutoCommit や ChopBlanks といった属性だけを取り扱わなければなりません。

よい例は以下のようになります:

  sub STORE
  {
      my ($dbh, $attr, $val) = @_;
      if ($attr eq 'AutoCommit') {
          # AutoCommit is currently the only standard attribute we have
          # to consider.
          if (!$val) { die "Can't disable AutoCommit"; }
          return 1;
      }
      if ($attr =~ m/^drv_/) {
          # Handle only our private attributes here
          # Note that we could trigger arbitrary actions.
          # Ideally we should warn about unknown attributes.
          $dbh->{$attr} = $val; # Yes, we are allowed to do this,
          return 1;             # but only for our private attributes
      }
      # Else pass up to DBI to handle for us
      $dbh->SUPER::STORE($attr, $val);
  }

  sub FETCH
  {
      my ($dbh, $attr) = @_;
      if ($attr eq 'AutoCommit') { return 1; }
      if ($attr =~ m/^drv_/) {
          # Handle only our private attributes here
          # Note that we could trigger arbitrary actions.
          return $dbh->{$attr}; # Yes, we are allowed to do this,
                                # but only for our private attributes
      }
      # Else pass up to DBI to handle
      $dbh->SUPER::FETCH($attr);
  }

DBI は実際には警告もエラーもなしに、ドライバ特有の属性(すべて小文字の 名前で)を格納し、取り出します。 そのため値の取得や設定で特別なロジック／チェックを必要としないのであれば、 実際には FETCH() や STORE() メソッドに、ドライバ特有のコードは何も 実装する必要はありません。

Unless your driver documentation indicates otherwise, the return value of the STORE() method is unspecified and the caller shouldn't use that value. (TBT)

その他のデータベースハンドルメソッド¶

この後に他のデータベースハンドルメソッドをいれることができます。 (DBIのデフォルトが正しくなければ)特に(ひっとしたら空かもしれない disconnect() メソッド、quote() メソッドについてよく検討してください。 この文書の他の場所に記述されている、type_info_all() と get_info() メソッドも必要でしょう。

Where reasonable use $h->SUPER::foo() to call the DBI's method in some or all cases and just wrap your custom behavior around that. (TBT)

If you want to use private trace flags you'll probably want to be able to set them by name. To do that you'll need to define a parse_trace_flag() method (note that's "parse_trace_flag", singular, not "parse_trace_flags", plural). (TBT)

  sub parse_trace_flag {
      my ($h, $name) = @_;
      return 0x01000000 if $name eq 'foo';
      return 0x02000000 if $name eq 'bar';
      return 0x04000000 if $name eq 'baz';
      return 0x08000000 if $name eq 'boo';
      return 0x10000000 if $name eq 'bop';
      return $h->SUPER::parse_trace_flag($name);
  }

All private flag names must be lowercase, and all private flags must be in the top 8 of the 32 bits. (TBT)

The DBD::Driver::st package¶

This package follows the same pattern the others do: (TBT)

  package DBD::Driver::st;

  $DBD::Driver::st::imp_data_size = 0;

The execute() and bind_param() methods¶

ここでパラメータバインディングを考慮しなければならないために、これが多分 最も難しいメソッドです。 これに加えて、正しく動作するために継承された DBI メソッドに 設定しなければならない多くの文属性があります (後述する "Statement attributes" を参照してください)。

上記から drv_params 属性を使うことにより簡単になった実装を示します:

  sub bind_param
  {
      my ($sth, $pNum, $val, $attr) = @_;
      my $type = (ref $attr) ? $attr->{TYPE} : $attr;
      if ($type) {
          my $dbh = $sth->{Database};
          $val = $dbh->quote($sth, $type);
      }
      my $params = $sth->{drv_params};
      $params->[$pNum-1] = $val;
      1;
  }

  sub execute
  {
      my ($sth, @bind_values) = @_;

      # start of by finishing any previous execution if still active
      $sth->finish if $sth->FETCH('Active');

      my $params = (@bind_values) ?
          \@bind_values : $sth->{drv_params};
      my $numParam = $sth->FETCH('NUM_OF_PARAMS');
      return $sth->set_err($DBI::stderr, "Wrong number of parameters")
          if @$params != $numParam;
      my $statement = $sth->{'Statement'};
      for (my $i = 0;  $i < $numParam;  $i++) {
          $statement =~ s/?/$params->[$i]/; # XXX doesn't deal with quoting etc!
      }
      # Do anything ... we assume that an array ref of rows is
      # created and store it:
      $sth->{'drv_data'} = $data;
      $sth->{'drv_rows'} = @$data; # number of rows
      $sth->STORE('NUM_OF_FIELDS') = $numFields;
      $sth->{Active} = 1;
      @$data || '0E0';
  }

ここでいくつか注意しなければならないがあります。

ここで NUM_OF_FIELDS 属性を設定することです。 というのも bind_columns() 属性が機能するためには必須だからです。

そして属性 $sth->{Statement} を使います; これは prepare() の中で生成しています。 属性 $sth->{Database}、これは dth 以外のなにものでもないのですが、 自動的に DBI によって作成されます。

最後に、(DBI 仕様で指定されている通り) 数値 0 ではなく、 文字列 '0E0' を返すことに注意してください; そのため結果のテストは新ですが 0 と等しいです。

  $sth->execute() or die $sth->errstr;

The execute_array(), execute_for_fetch() and bind_param_array() methods¶

In general, DBD's only need to implement execute_for_fetch() and bind_param_array. DBI's default execute_array() will invoke the DBD's execute_for_fetch() as needed. (TBT)

The following sequence describes the interaction between DBI execute_array and a DBD's execute_for_fetch: (TBT)

1. App calls $sth->execute_array(\%attrs, @array_of_arrays)

   App calls $sth->execute_array(\%attrs, @array_of_arrays) (TBT)

2. If @array_of_arrays was specified, DBI processes @array_of_arrays by calling DBD's bind_param_array(). Alternately, App may have directly called bind_param_array()

   If @array_of_arrays was specified, DBI processes @array_of_arrays by calling DBD's bind_param_array(). Alternately, App may have directly called bind_param_array() (TBT)

3. DBD validates and binds each array

   DBD validates and binds each array (TBT)

4. DBI retrieves the validated param arrays from DBD's ParamArray attribute

   DBI retrieves the validated param arrays from DBD's ParamArray attribute (TBT)

5. DBI calls DBD's execute_for_fetch($fetch_tuple_sub, \@tuple_status), where &$fetch_tuple_sub is a closure to iterate over the returned ParamArray values, and \@tuple_status is an array to receive the disposition status of each tuple.

   DBI calls DBD's execute_for_fetch($fetch_tuple_sub, \@tuple_status), where &$fetch_tuple_sub is a closure to iterate over the returned ParamArray values, and \@tuple_status is an array to receive the disposition status of each tuple. (TBT)

6. DBD iteratively calls &$fetch_tuple_sub to retrieve parameter tuples to be added to its bulk database operation/request.

   DBD iteratively calls &$fetch_tuple_sub to retrieve parameter tuples to be added to its bulk database operation/request. (TBT)

7. when DBD reaches the limit of tuples it can handle in a single database operation/request, or the &$fetch_tuple_sub indicates no more tuples by returning undef, the DBD executes the bulk operation, and reports the disposition of each tuple in \@tuple_status.

   when DBD reaches the limit of tuples it can handle in a single database operation/request, or the &$fetch_tuple_sub indicates no more tuples by returning undef, the DBD executes the bulk operation, and reports the disposition of each tuple in \@tuple_status. (TBT)

8. DBD repeats steps 6 and 7 until all tuples are processed.

   DBD repeats steps 6 and 7 until all tuples are processed. (TBT)

E.g., here's the essence of DBD::Oracle's execute_for_fetch: (TBT)

       while (1) {
           my @tuple_batch;
           for (my $i = 0; $i < $batch_size; $i++) {
                push @tuple_batch, [ @{$fetch_tuple_sub->() || last} ];
           }
           last unless @tuple_batch;
           my $res = ora_execute_array($sth, \@tuple_batch,
              scalar(@tuple_batch), $tuple_batch_status);
           push @$tuple_status, @$tuple_batch_status;
       }

Note that DBI's default execute_array()/execute_for_fetch() implementation requires the use of positional (i.e., '?') placeholders. Drivers which require named placeholders must either emulate positional placeholders (e.g., see DBD::Oracle), or must implement their own execute_array()/execute_for_fetch() methods to properly sequence bound parameter arrays. (TBT)

Fetching data¶

Only one method needs to be written for fetching data, fetchrow_arrayref(). The other methods, fetchrow_array(), fetchall_arrayref(), etc, as well as the database handle's select* methods are part of DBI, and call fetchrow_arrayref() as necessary. (TBT)

  sub fetchrow_arrayref
  {
      my ($sth) = @_;
      my $data = $sth->{drv_data};
      my $row = shift @$data;
      if (!$row) {
          $sth->STORE(Active => 0); # mark as no longer active
          return undef;
      }
      if ($sth->FETCH('ChopBlanks')) {
          map { $_ =~ s/\s+$//; } @$row;
      }
      return $sth->_set_fbav($row);
  }
  *fetch = \&fetchrow_arrayref; # required alias for fetchrow_arrayref

メソッド _set_fbav を使っていることに注意してください -- これは bind_col() や bind_columns() が機能するために必要です。

If an error occurs which leaves the $sth in a state where remaining rows can't be fetched then Active should be turned off before the method returns. (TBT)

The rows() method for this driver can be implemented like this: (TBT)

  sub rows { shift->{drv_rows} }

because it knows in advance how many rows it has fetched. Alternatively you could delete that method and so fallback to the DBI's own method which does the right thing based on the number of calls to _set_fbav(). (TBT)

The more_results method¶

If your driver doesn't support multiple result sets, then don't even implement this method. (TBT)

Otherwise, this method needs to get the statement handle ready to fetch results from the next result set, if there is one. Typically you'd start with: (TBT)

    $sth->finish;

then you should delete all the attributes from the attribute cache that may no longer be relevant for the new result set: (TBT)

    delete $sth->{$_}
        for qw(NAME TYPE PRECISION SCALE ...);

for drivers written in C use: (TBT)

    hv_delete((HV*)SvRV(sth), "NAME", 4, G_DISCARD);
    hv_delete((HV*)SvRV(sth), "NULLABLE", 8, G_DISCARD);
    hv_delete((HV*)SvRV(sth), "NUM_OF_FIELDS", 13, G_DISCARD);
    hv_delete((HV*)SvRV(sth), "PRECISION", 9, G_DISCARD);
    hv_delete((HV*)SvRV(sth), "SCALE", 5, G_DISCARD);
    hv_delete((HV*)SvRV(sth), "TYPE", 4, G_DISCARD);

Don't forget to also delete, or update, any driver-private attributes that may not be correct for the next resultset. (TBT)

The NUM_OF_FIELDS attribute is a special case. It should be set using STORE: (TBT)

    $sth->STORE(NUM_OF_FIELDS => 0); /* for DBI <= 1.53 */
    $sth->STORE(NUM_OF_FIELDS => $new_value);

for drivers written in C use this incantation: (TBT)

    /* Adjust NUM_OF_FIELDS - which also adjusts the row buffer size */
    DBIc_NUM_FIELDS(imp_sth) = 0; /* for DBI <= 1.53 */
    DBIc_STATE(imp_xxh)->set_attr_k(sth, sv_2mortal(newSVpvn("NUM_OF_FIELDS",13)), 0,
        sv_2mortal(newSViv(mysql_num_fields(imp_sth->result)))
    );

For DBI versions prior to 1.54 you'll also need to explicitly adjust the number of elements in the row buffer array (DBIc_FIELDS_AV(imp_sth)) to match the new result set. Fill any new values with newSV(0) not &sv_undef. Alternatively you could free DBIc_FIELDS_AV(imp_sth) and set it to null, but that would mean bind_columns() wouldn't work across result sets. (TBT)

Statement attributes¶

dbh と sth 属性の主な違いは、ここでは DBI によって要求されている たくさんの属性を実装しなければならないことです。 例えば: NAME, NULLABLE, TYPE など。 完全なリストについては "Statement Handle Attributes" in DBI を 参照してください。

Pay attention to attributes which are marked as read only, such as NUM_OF_PARAMS. These attributes can only be set the first time a statement is executed. If a statement is prepared, then executed multiple times, warnings may be generated. (TBT)

You can protect against these warnings, and prevent the recalculation of attributes which might be expensive to calculate (such as the NAME and NAME_* attributes): (TBT)

    my $storedNumParams = $sth->FETCH('NUM_OF_PARAMS');
    if (!defined $storedNumParams or $storedNumFields < 0) {
        $sth->STORE('NUM_OF_PARAMS') = $numParams;

        # Set other useful attributes that only need to be set once
        # for a statement, like $sth->{NAME} and $sth->{TYPE}
    }

One particularly important attribute to set correctly (mentioned in "ATTRIBUTES COMMON TO ALL HANDLES" in DBI is Active. Many DBI methods, including bind_columns(), depend on this attribute. (TBT)

STORE() と FETCH() のほかのメソッドは概ね上記の dbh のものと 同じです。

Other statement methods¶

平凡な finish() メソッドは格納されたデータを捨て、(Active のような) 全ての属性をリセットし、$sth->SUPER::finish() をします。

If you've defined a parse_trace_flag() method in ::db you'll also want it in ::st, so just alias it in: (TBT)

  *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;

そしておそらく DBI 仕様にはないいくつかの他のメソッド、特に メタデータの作成が利用可能です。 これらは、install_method() を使ってインストールできるように、 ドライバが登録した接頭辞で始まる名前を持たなければならないことを 忘れないでください。

If DESTROY() is called on a statement handle that's still active ($sth->{Active} is true) then it should effectively call finish(). (TBT)

    sub DESTROY {
        my $sth = shift;
        $sth->finish if $sth->FETCH('Active');
    }

テスト¶

テストプロセスは Perl 標準規約(Perl standard test harness)にできるだけ 従うべきです。

特にテストのほとんど(全て)は t サブディレクトリで 実行されなければなりません。 そして make test で実行されたときには単純に ok だけを生成するべきです。 これがどのようにするかについての詳細についてはラクダ本の 第 7 章「標準 Perl ライブラリ」の Test::Harness のセクションを ごらんください。

テストはテストするために使われるデータベースのタイプやドライバを テストするユーザの権限に合わせる必要があるかもしれません。 例えば、DBD::Informix のテストコードは多くの場所で、異なった Informix データベースが異なった能力を持っているのに合わせて、 接続されているデータベースのタイプに順応しなければなりません: テストの一部はトランザクションログのないデータベースのためのものです; 残りはトランザクションログのあるデータベースのためのものです; サーバはブログ、ストアードプロシージャ、ユーザー定義データ型に 対応しているものといないものがあります。

When a complete file of tests must be skipped, you can provide a reason in a pseudo-comment: (TBT)

    if ($no_transactions_available)
    {
        print "1..0 # Skip: No transactions available\n";
        exit 0;
    }

Consider downloading the DBD::Informix code and look at the code in DBD/Informix/TestHarness.pm which is used throughout the DBD::Informix tests in the t sub-directory. (TBT)

C/XS ドライバを作る¶

Please also see the section under "CREATING A PURE PERL DRIVER" regarding the creation of the Makefile.PL. (TBT)

ありあわせからC/XSドライバを作成することは、気の重たくなる作業です。 参照となるドライバ実装をピックアップし、それをドライバを書こうとしている データベース製品にあうように改造することによってかなり簡単に することができますし、するべきです。

事実上のリファレンスドライバは DBI パッケージの作者でもある Tim Bunce によって書かれた DBD::Oracle でした。 DBD::Oracle モジュールは C レベル API によって実装されている、 よい例です。

今日では Tim とJeff Urlwin によってメンテナンスされている DBD::ODBC という別のドライバを元にしたほうがよいようです。 というのも数多くのメタデータを提供していますし、将来の開発のための ガイドラインとなるようにも思われます(DBD::Oracle も Oracle 8 OCI インターフェースに深く掘り下げているので、いまでは ほんのわずかの差しかないでしょう)。

DBD::Informix ドライバは、関数ベース API ではなく埋め込みSQL (embedded SQL)を使ったドライバのよいリファレンスです。 DBD::Ingress も一見の価値があります。

C/XS 版の Driver.pm¶

A lot of the code in the Driver.pm file is very similar to the code for pure Perl modules - see above. However, there are also some subtle (and not so subtle) differences, including: (TBT)

• The variables $DBD::Driver::{dr|db|st}::imp_data_size are not defined here, but in the XS code, because they declare the size of certain C structures.

  変数 $DBD::Driver::{dr|db|st}::imp_data_size は、ここで定義されません; かわりにXSのコードの中で定義されます; というのも、それらはあるCの 構造体の大きさを宣言しているからです。

• Some methods are typically moved to the XS code, in particular prepare(), execute(), disconnect(), disconnect_all() and the STORE() and FETCH() methods.

  典型的にはいくつかのメソッド、特に prepare(), execute(), disconnect(), disconnect_all() そして STORE() および FETCH() メソッドは XS コードに移っています。

• Other methods are still part of Driver.pm, but have callbacks to the XS code.

  他のメソッドはまだ Driver.pm の一部ですが、XS コードにコールバックを 持っています。

• If the driver-specific parts of the imp_drh_t structure need to be formally initialized (which does not seem to be a common requirement), then you need to add a call to an appropriate XS function in the driver method of DBD::Driver::driver(), and you define the corresponding function in Driver.xs, and you define the C code in dbdimp.c and the prototype in dbdimp.h.

  If the driver-specific parts of the imp_drh_t structure need to be formally initialized (which does not seem to be a common requirement), then you need to add a call to an appropriate XS function in the driver method of DBD::Driver::driver(), and you define the corresponding function in Driver.xs, and you define the C code in dbdimp.c and the prototype in dbdimp.h. (TBT)

  For example, DBD::Informix has such a requirement, and adds the following call after the call to _new_drh() in Informix.pm:

  For example, DBD::Informix has such a requirement, and adds the following call after the call to _new_drh() in Informix.pm: (TBT)

    DBD::Informix::dr::driver_init($drh);

  and the following code in Informix.xs:

  and the following code in Informix.xs: (TBT)

    # Initialize the DBD::Informix driver data structure
    void
    driver_init(drh)
        SV *drh
        CODE:
        ST(0) = dbd_ix_dr_driver_init(drh) ? &sv_yes : &sv_no;

  and the code in dbdimp.h declares:

  and the code in dbdimp.h declares: (TBT)

    extern int dbd_ix_dr_driver_init(SV *drh);

  and the code in dbdimp.ec (equivalent to dbdimp.c) defines:

  and the code in dbdimp.ec (equivalent to dbdimp.c) defines: (TBT)

    /* Formally initialize the DBD::Informix driver structure */
    int
    dbd_ix_dr_driver(SV *drh)
    {
        D_imp_drh(drh);
        imp_drh->n_connections = 0;       /* No active connections */
        imp_drh->current_connection = 0;  /* No current connection */
        imp_drh->multipleconnections = (ESQLC_VERSION >= 600) ? True : False;
        dbd_ix_link_newhead(&imp_drh->head);  /* Empty linked list of connections */
        return 1;
    }

  DBD::Oracle has a similar requirement but gets around it by checking whether the private data part of the driver handle is all zeroed out, rather than add extra functions.

  DBD::Oracle has a similar requirement but gets around it by checking whether the private data part of the driver handle is all zeroed out, rather than add extra functions. (TBT)

さあ例として Oracle.pm (revised heavily to remove idiosyncrasies) の一部をさらに詳しく見てみましょう; 既にピュア Perl ドライバで 説明したことは無視します。

The connect method¶

The connect method is the database handle constructor. You could write either of two versions of this method: either one which takes connection attributes (new code) and one which ignores them (old code only). (TBT)

If you ignore the connection attributes, then you omit all mention of the $auth variable (which is a reference to a hash of attributes), and the XS system manages the differences for you. (TBT)

  sub connect
  {
      my ($drh, $dbname, $user, $auth, $attr) = @_;

      # Some database specific verifications, default settings
      # and the like following here. This should only include
      # syntax checks or similar stuff where it's legal to
      # 'die' in case of errors.

      my $dbh = DBI::_new_dbh($drh, {
              'Name'   => $dbname,
          })
          or return undef;

      # Call the driver-specific function _login in Driver.xs file which
      # calls the DBMS-specific function(s) to connect to the database,
      # and populate internal handle data.
      DBD::Driver::db::_login($dbh, $dbname, $user, $auth, $attr)
          or return undef;

      $dbh;
  }

これはピュア Perl の場合とほとんど同じです。 違いはプライベートな _login() コールバック (これは実際にデータベースに接続します) を使っていることです; これは Driver.xst で実装されます(あなたはこれを実装するべきでは ありません)そして dbdimp.c から dbd_db_login6() または dbd_db_login6_sv を呼び出します。 詳細は下記をご覧下さい。

If your driver has driver-specific attributes which may be passed in the connect method and hence end up in $attr in dbd_db_login6 then it is best to delete any you process so DBI does not send them again via STORE after connect. You can do this in C like this: (TBT)

  DBD_ATTRIB_DELETE(attr, "my_attribute_name",
                    strlen("my_attribute_name"));

However, prior to DBI subversion version 11605 (and fixed post 1.607) DBD_ATTRIB_DELETE segfaulted so if you cannot guarantee the DBI version will be post 1.607 you need to use: (TBT)

  hv_delete((HV*)SvRV(attr), "my_attribute_name",
                     strlen("my_attribute_name"), G_DISCARD);

 *FIX ME* Discuss removing attributes in Perl code.

The disconnect_all method¶

 *FIX ME* T.B.S

The data_sources method¶

If your data_sources() method can be implemented in pure Perl, then do so because it is easier than doing it in XS code (see the section above for pure Perl drivers). (TBT)

If your data_sources() method must call onto compiled functions, then you will need to define dbd_dr_data_sources in your dbdimp.h file, which will trigger Driver.xst (in DBI v1.33 or greater) to generate the XS code that calls your actual C function (see the discussion below for details) and you do not code anything in Driver.pm to handle it. (TBT)

The prepare method¶

prepare メソッドは文ハンドルのコンストラクタで、 そのほとんどは new ではありません。 connect() メソッドと同様に、C コールバックを持ちます:

  package DBD::Driver::db; # ====== DATABASE ======
  use strict;

  sub prepare
  {
      my ($dbh, $statement, $attribs) = @_;

      # create a 'blank' sth
      my $sth = DBI::_new_sth($dbh, {
          'Statement' => $statement,
          })
          or return undef;

      # Call the driver-specific function _prepare in Driver.xs file
      # which calls the DBMS-specific function(s) to prepare a statement
      # and populate internal handle data.
      DBD::Driver::st::_prepare($sth, $statement, $attribs)
          or return undef;
      $sth;
  }

The execute method¶

 *FIX ME* T.B.S

The fetchrow_arrayref method¶

 *FIX ME* T.B.S

Other methods?¶

 *FIX ME* T.B.S

Driver.xs¶

Driver.xs は以下のような感じになります:

  #include "Driver.h"

  DBISTATE_DECLARE;

  INCLUDE: Driver.xsi

  MODULE = DBD::Driver    PACKAGE = DBD::Driver::dr

  /* Non-standard drh XS methods following here, if any.       */
  /* If none (the usual case), omit the MODULE line above too. */

  MODULE = DBD::Driver    PACKAGE = DBD::Driver::db

  /* Non-standard dbh XS methods following here, if any.       */
  /* Currently this includes things like _list_tables from     */
  /* DBD::mSQL and DBD::mysql.                                 */

  MODULE = DBD::Driver    PACKAGE = DBD::Driver::st

  /* Non-standard sth XS methods following here, if any.       */
  /* In particular this includes things like _list_fields from */
  /* DBD::mSQL and DBD::mysql for accessing metadata.          */

特にここで Driver.xsi のインクルードに注意してください: DBI は、ほとんどのプライベートなメソッドのためのスタブ関数をここに 入れており、それらは通常はあなたに代っていろんな機能をします。

なにかを本当に実装する必要があるときには、dbdimp.c でプライベートな 関数を呼びます; これがあなたは実装しなけばならないものです。

You need to set up an extra routine if your driver needs to export constants of its own, analogous to the SQL types available when you say: (TBT)

  use DBI qw(:sql_types);

 *FIX ME* T.B.S

Driver.h¶

Driver.h はとても単純で、以下のようになります:

  #ifndef DRIVER_H_INCLUDED
  #define DRIVER_H_INCLUDED

  #define NEED_DBIXS_VERSION 93    /* 93 for DBI versions 1.00 to 1.51+ */
  #define PERL_NO_GET_CONTEXT      /* if used require DBI 1.51+ */

  #include <DBIXS.h>      /* installed by the DBI module  */

  #include "dbdimp.h"

  #include "dbivport.h"   /* see below                    */

  #include <dbd_xsh.h>    /* installed by the DBI module  */

  #endif /* DRIVER_H_INCLUDED */

The DBIXS.h header defines most of the interesting information that the writer of a driver needs. (TBT)

The file dbd_xsh.h header provides prototype declarations for the C functions that you might decide to implement. Note that you should normally only define one of dbd_db_login(), dbd_db_login6() or dbd_db_login6_sv unless you are intent on supporting really old versions of DBI (prior to DBI 1.06) as well as modern versions. The only standard, DBI-mandated functions that you need write are those specified in the dbd_xsh.h header. You might also add extra driver-specific functions in Driver.xs. (TBT)

The dbivport.h file should be copied from the latest DBI release into your distribution each time you modify your driver. Its job is to allow you to enhance your code to work with the latest DBI API while still allowing your driver to be compiled and used with older versions of the DBI (for example, when the DBIh_SET_ERR_CHAR() macro was added to DBI 1.41, an emulation of it was added to dbivport.h). This makes users happy and your life easier. Always read the notes in dbivport.h to check for any limitations in the emulation that you should be aware of. (TBT)

With DBI v1.51 or better I recommend that the driver defines PERL_NO_GET_CONTEXT before DBIXS.h is included. This can significantly improve efficiency when running under a thread enabled perl. (Remember that the standard perl in most Linux distributions is built with threads enabled. So is ActiveState perl for Windows, and perl built for Apache mod_perl2.) If you do this there are some things to keep in mind: (TBT)

• If PERL_NO_GET_CONTEXT is defined, then every function that calls the Perl API will need to start out with a dTHX; declaration.

  If PERL_NO_GET_CONTEXT is defined, then every function that calls the Perl API will need to start out with a dTHX; declaration. (TBT)

• You'll know which functions need this, because the C compiler will complain that the undeclared identifier my_perl is used if and only if the perl you are using to develop and test your driver has threads enabled.

  You'll know which functions need this, because the C compiler will complain that the undeclared identifier my_perl is used if and only if the perl you are using to develop and test your driver has threads enabled. (TBT)

• If you don't remember to test with a thread-enabled perl before making a release it's likely that you'll get failure reports from users who are.

  If you don't remember to test with a thread-enabled perl before making a release it's likely that you'll get failure reports from users who are. (TBT)

• For driver private functions it is possible to gain even more efficiency by replacing dTHX; with pTHX_ prepended to the parameter list and then aTHX_ prepended to the argument list where the function is called.

  For driver private functions it is possible to gain even more efficiency by replacing dTHX; with pTHX_ prepended to the parameter list and then aTHX_ prepended to the argument list where the function is called. (TBT)

See "How multiple interpreters and concurrency are supported" in perlguts for additional information about PERL_NO_GET_CONTEXT. (TBT)

ヘッダ dbdimp.h の実装¶

このヘッダファイルは二つの役割があります:

第一にハンドルのプライベートな部分のためのデータ構造を定義します。

第二に dbd_db_login() のような一般的な名前を ora_db_login() のような データベース特有の名前に変更するマクロを定義します。 これにより名前の衝突をさけ、静的にリンクされた Perl で動かしたときに 異なるドライバを使うことを可能になります。

実装したくないXSメソッドを使えなくするという重要な働きも持っています。

最後にいくつかの関数の代りの実装を選ぶためにもマクロが使われます。 例えば、現在定義されている dbd_db_login() 関数には属性ハッシュは 渡されません。

Since DBI v1.06, if a dbd_db_login6() macro is defined (for a function with 6 arguments), it will be used instead with the attribute hash passed as the sixth argument. (TBT)

Since DBI post v1.607, if a dbd_db_login6_sv() macro is defined (for a function like dbd_db_login6 but with scalar pointers for the dbname, username and password), it will be used instead. This will allow your login6 function to see if there are any Unicode characters in the dbname. (TBT)

Oracle の dbdimp.c だけをピックアップし、いくつかの名前、構造体、 データ型を使う人々がいますが、私はこれには強く反対の勧告をします。 一見、これは時間を節約するように見えますが、あなたの実装を 読みにくくしてしまいます。 DBI 仕様と Oracle 特有の部分、mSQL 特有の部分、mysql 特有の部分を DBD::mysql の dbdimp.h と dbdimp.c (DBD::mysql は DBD::Oracle を基本とした DBD::mSQL のポートです)を 分けるというのは地獄です。 [1996 年に継承したバージョンは DBD::Oracle のみに基づいていましたが、 DBD::Informix を分解した経験に基づき、賛成します。]

ドライバのこの部分は あなたの独占部分 です。 一から書きなおしましょう; そうすることによりきれいで短くなります: 言い換えればよりよいコード片になります。 (もちろん他の人たちの作品も見てください。)

  struct imp_drh_st {
      dbih_drc_t com;           /* MUST be first element in structure   */
      /* Insert your driver handle attributes here */
  };

  struct imp_dbh_st {
      dbih_dbc_t com;           /* MUST be first element in structure   */
      /* Insert your database handle attributes here */
  };

  struct imp_sth_st {
      dbih_stc_t com;           /* MUST be first element in structure   */
      /* Insert your statement handle attributes here */
  };

  /*  Rename functions for avoiding name clashes; prototypes are  */
  /*  in dbd_xst.h                                                */
  #define dbd_init            drv_dr_init
  #define dbd_db_login6_sv    drv_db_login_sv
  #define dbd_db_do           drv_db_do
  ... many more here ...

これらの構造体はハンドルのプライベートな部分を実装します。

imp_dbh_{dr|db|st} という名前を使う 必要があり、最初のフィールドの型は dbih_drc_t|_dbc_t|_stc_t でなければ ならず、com を呼び出さなければ なりません。

以下に示す DBIc_xxx() を使う以外に、このフィールドに 直接アクセスしてはいけません。

ソース dbdimp.c の実装¶

Conventionally, dbdimp.c is the main implementation file (but DBD::Informix calls the file dbdimp.ec). This section includes a short note on each function that is used in the Driver.xsi template and thus has to be implemented. (TBT)

Of course, you will probably also need to implement other support functions, which should usually be file static if they are placed in dbdimp.c. If they are placed in other files, you need to list those files in Makefile.PL (and MANIFEST) to handle them correctly. (TBT)

It is wise to adhere to a namespace convention for your functions to avoid conflicts. For example, for a driver with prefix drv_, you might call externally visible functions dbd_drv_xxxx. You should also avoid non-constant global variables as much as possible to improve the support for threading. (TBT)

Since Perl requires support for function prototypes (ANSI or ISO or Standard C), you should write your code using function prototypes too. (TBT)

It is possible to use either the unmapped names such as dbd_init() or the mapped names such as dbd_ix_dr_init() in the dbdimp.c file. DBD::Informix uses the mapped names which makes it easier to identify where to look for linkage problems at runtime (which will report errors using the mapped names). (TBT)

Most other drivers, and in particular DBD::Oracle, use the unmapped names in the source code which makes it a little easier to compare code between drivers and eases discussions on the dbi-dev mailing list. The majority of the code fragments here will use the unmapped names. (TBT)

Ultimately, you should provide implementations for most of the functions listed in the dbd_xsh.h header. The exceptions are optional functions (such as dbd_st_rows()) and those functions with alternative signatures, such as dbd_db_login6_sv, dbd_db_login6() and dbd_db_login(). Then you should only implement one of the alternatives, and generally the newer one of the alternatives. (TBT)

The dbd_init method¶

  #include "Driver.h"

  DBISTATE_DECLARE;

  void dbd_init(dbistate_t* dbistate)
  {
      DBISTATE_INIT;  /*  Initialize the DBI macros  */
  }

dbd_init() はドライバが初めてロードされたときに呼ばれます; the bootstrap command in DBD::Driver::dr::driver() triggers this, and the call is generated in the BOOT section of Driver.xst. これらの文は DBI マクロを使用するために必要です。 それらはプライベートなヘッダファイル dbdimp.h に代わりに インクルードされます。 DBISTATE_INIT は、dbistate() から呼び出されるために、 dbd_init() への引数の名前が必要であることに注意してください。

The dbd_drv_error method¶

DBI が適切にアクセスできるようなエラーの記録を取り扱う関数が必要です。 好きな名前をつけることができますが、ここでは dbd_drv_error() と呼びます。

The argument list depends on your database software; different systems provide different ways to get at error information. (TBT)

  static void dbd_drv_error(SV *h, int rc, const char *what)
  {

h が汎用的なハンドルであること、それはドライバハンドル、 データベースまたは文ハンドルでありうることに注意してください。

      D_imp_xxh(h);

このマクロは変数 imp_xxh を宣言し、プライベートなハンドルポンンタへの ポインタで初期化します。 これを imp_drh_t, imp_dbh_t, imp_sth_t にキャストすることもできます。

To record the error correctly, equivalent to the set_err() method, use one of the DBIh_SET_ERR_CHAR(...) or DBIh_SET_ERR_SV(...) macros, which were added in DBI 1.41: (TBT)

  DBIh_SET_ERR_SV(h, imp_xxh, err, errstr, state, method);
  DBIh_SET_ERR_CHAR(h, imp_xxh, err_c, err_i, errstr, state, method);

For DBIh_SET_ERR_SV the err, errstr, state, and method parameters are SV* (use &sv_undef instead of NULL). (TBT)

For DBIh_SET_ERR_CHAR the err_c, errstr, state, method parameters are char*. (TBT)

The err_i parameter is an IV that's used instead of err_c if err_c is Null. (TBT)

The method parameter can be ignored. (TBT)

The DBIh_SET_ERR_CHAR macro is usually the simplest to use when you just have an integer error code and an error message string: (TBT)

  DBIh_SET_ERR_CHAR(h, imp_xxh, Nullch, rc, what, Nullch, Nullch);

As you can see, any parameters that aren't relevant to you can be Null. (TBT)

To make drivers compatible with DBI < 1.41 you should be using dbivport.h as described in "Driver.h" above. (TBT)

The (obsolete) macros such as DBIh_EVENT2 should be removed from drivers. (TBT)

The names dbis and DBIS, which were used in previous versions of this document, should be replaced with the DBIc_STATE(imp_xxh) macro. (TBT)

The name DBILOGFP, which was also used in previous versions of this document, should be replaced by DBIc_LOGPIO(imp_xxh). (TBT)

Your code should not call the C <stdio.h> I/O functions; you should use PerlIO_printf() as shown: (TBT)

      if (DBIc_TRACE_LEVEL(imp_xxh) >= 2)
          PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar %s: %s\n",
              foo, neatsvpv(errstr,0));

DBI ドライバの中でトレースログがどのように動くのかをみるのは、これが 初めてです。 できるだけ多くこれを使ってください; しかしトレースレベルが 3 未満の場合は 何も出力しません。 レベル 1 と 2 は DBI のために予約されています。

You can define up to 8 private trace flags using the top 8 bits of DBIc_TRACE_FLAGS(imp), that is: 0xFF000000. See the parse_trace_flag() method elsewhere in this document. (TBT)

The dbd_dr_data_sources method¶

This method is optional; the support for it was added in DBI v1.33. (TBT)

As noted in the discussion of Driver.pm, if the data sources can be determined by pure Perl code, do it that way. If, as in DBD::Informix, the information is obtained by a C function call, then you need to define a function that matches the prototype: (TBT)

  extern AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attrs);

An outline implementation for DBD::Informix follows, assuming that the sqgetdbs() function call shown will return up to 100 databases names, with the pointers to each name in the array dbsname and the name strings themselves being stores in dbsarea. (TBT)

  AV *dbd_dr_data_sources(SV *drh, imp_drh_t *imp_drh, SV *attr)
  {
      int ndbs;
      int i;
      char *dbsname[100];
      char  dbsarea[10000];
      AV *av = Nullav;

      if (sqgetdbs(&ndbs, dbsname, 100, dbsarea, sizeof(dbsarea)) == 0)
      {
          av = NewAV();
          av_extend(av, (I32)ndbs);
          sv_2mortal((SV *)av);
          for (i = 0; i < ndbs; i++)
            av_store(av, i, newSVpvf("dbi:Informix:%s", dbsname[i]));
      }
      return(av);
  }

The actual DBD::Informix implementation has a number of extra lines of code, logs function entry and exit, reports the error from sqgetdbs(), and uses #define'd constants for the array sizes. (TBT)

The dbd_db_login6 method¶

  int dbd_db_login6_sv(SV* dbh, imp_dbh_t* imp_dbh, SV* dbname,
                       SV* user, SV* auth, SV *attr);

  or

  int dbd_db_login6(SV* dbh, imp_dbh_t* imp_dbh, char* dbname,
                   char* user, char* auth, SV *attr);

この関数は実際にデータベースに接続します。 引数 dbh はデータベースハンドルです。 imp_dbh は上記 dbd_drv_error() の imp_xxx のように、 プライベートデータへのポインタです。 引数 dbname, user, auth, attr はドライバハンドルの connect() メソッドに対応します。

ここでは、たくさんのデータベース特有の属性を使うでしょう、それらは DSN で指定されます。 (Perl を使って) DSN を connect() メソッドで解析し、_login() から dbd_db_login6() にハンドル属性として渡すことをお勧めします。

それらをどのように取り出すか、hostname 属性をを使う例を示します; null 終端子を除いて 12 文字までです:

  SV** svp;
  STRLEN len;
  char* hostname;

  if ( (svp = DBD_ATTRIB_GET_SVP(attr, "drv_hostname", 12)) && SvTRUE(*svp)) {
      hostname = SvPV(*svp, len);
      DBD_ATTRIB_DELETE(attr, "drv_hostname", 12); /* avoid later STORE */
  } else {
      hostname = "localhost";
  }

If you handle any driver specific attributes in the dbd_db_login6 method you probably want to delete them from attr (as above with DBD_ATTRIB_DELETE). If you don't delete your handled attributes DBI will call STORE for each attribute after the connect/login and this is at best redundant for attributes you have already processed. (TBT)

Note: Until revision 11605 (post DBI 1.607), there was a problem with DBD_ATTRIBUTE_DELETE so unless you require a DBI version after 1.607 you need to replace each DBD_ATTRIBUTE_DELETE call with: (TBT)

  hv_delete((HV*)SvRV(attr), key, key_len, G_DISCARD)

Note that you can also obtain standard attributes such as AutoCommit and ChopBlanks from the attributes parameter, using DBD_ATTRIB_GET_IV for integer attributes. (TBT)

If, for example, your database does not support transactions but AutoCommit is set off (requesting transaction support), then you can emulate a 'failure to connect'. (TBT)

ついに実際にデータベースに接続しなければなりません。 一般的に、接続が失敗すると、ハンドルが個別に破壊する必要が内容に、 全ての割り当てられたリソースが解放されるようにするのが最良です。 もし成功すれば(あるいは失敗した場合であっても、リソースを占有していれば)、 以下のマクロを使わなければなりません:

  DBIc_IMPSET_on(imp_dbh);

これはそのドライバ(実装)が imp_dbh 構造体のなかでリソースを 占有していること、そしてそのハンドルが破壊されるとき、実装のプライベートな dbd_db_destroy() 関数が呼ばれなければならないことを示します。

  DBIc_ACTIVE_on(imp_dbh);

これはそのハンドラがサーバへのアクティブな接続を持っていること、そして そのハンドルが破壊される前にその dbd_db_disconnect() 関数が 呼ばれなければならないことを示します。

Note that if you do need to fail, you should report errors via the drh or imp_drh rather than via dbh or imp_dbh because imp_dbh will be destroyed by the failure, so errors recorded in that handle will not be visible to DBI, and hence not the user either. (TBT)

Note too, that the function is passed dbh and imp_dbh, and there is a macro D_imp_drh_from_dbh which can recover the imp_drh from the imp_dbh. However, there is no DBI macro to provide you with the drh given either the imp_dbh or the dbh or the imp_drh (and there's no way to recover the dbh given just the imp_dbh). (TBT)

This suggests that, despite the above notes about dbd_drv_error() taking an SV *, it may be better to have two error routines, one taking imp_dbh and one taking imp_drh instead. With care, you can factor most of the formatting code out so that these are small routines calling a common error formatter. See the code in DBD::Informix 1.05.00 for more information. (TBT)

dbd_db_login6() 関数は成功すれば TRUE、そうでなければ FALSE を返さなければなりません。

Drivers implemented long ago may define the five-argument function dbd_db_login() instead of dbd_db_login6(). The missing argument is the attributes. There are ways to work around the missing attributes, but they are ungainly; it is much better to use the 6-argument form. Even later drivers will use dbd_db_login6_sv() which provides the dbname, username and password as SVs. (TBT)

The dbd_db_commit and dbd_db_rollback methods¶

  int dbd_db_commit(SV *dbh, imp_dbh_t *imp_dbh);
  int dbd_db_rollback(SV* dbh, imp_dbh_t* imp_dbh);

これらはコミットとロールバックのために使われます。 成功すれば TRUE、そうでなければ FALSE を返さなければなりません。

引数 dbh とimp_dbh は上述の dbd_db_login6() と同じです; これ以降、これらが現れたときには説明を省略します。

These functions should return TRUE for success, FALSE otherwise. (TBT)

The dbd_db_disconnect method¶

これは disconnect() メソッドのプライベートな部分です。 ACTIVE フラグがオンになっている、すべての dbh は 切断されなければなりません。 (上記 dbd_db_connect() でそれを設定しなければならないことに注意。)

  int dbd_db_disconnect(SV* dbh, imp_dbh_t* imp_dbh);

データベースハンドルは成功すれば TRUE、そうでなければ FALSE を 返さなければなりません。 その場合には:

  DBIc_ACTIVE_off(imp_dbh);

リターンする前には DBI に dbd_db_disconnect() が実行されたことを 知らせるためにする必要があります。

Note that there's nothing to stop a dbh being disconnected while it still have active children. If your database API reacts badly to trying to use an sth in this situation then you'll need to add code like this to all sth methods: (TBT)

  if (!DBIc_ACTIVE(DBIc_PARENT_COM(imp_sth)))
    return 0;

Alternatively, you can add code to your driver to keep explicit track of the statement handles that exist for each database handle and arrange to destroy those handles before disconnecting from the database. There is code to do this in DBD::Informix. Similar comments apply to the driver handle keeping track of all the database handles. (TBT)

Note that the code which destroys the subordinate handles should only release the associated database resources and mark the handles inactive; it does not attempt to free the actual handle structures. (TBT)

This function should return TRUE for success, FALSE otherwise, but it is not clear what anything can do about a failure. (TBT)

The dbd_db_discon_all method¶

  int dbd_discon_all (SV *drh, imp_drh_t *imp_drh);

この関数はシャットダウンの時に呼ばれるかもしれません。 もし可能であれば−すべてのデータベースハンドルを切断するように全力を 尽くさなければなりません。 いくつかのデータベースはそれをサポートしていません。 その場合には 'success' を返すことしか出来ません。

This function should return TRUE for success, FALSE otherwise, but it is not clear what anything can do about a failure. (TBT)

The dbd_db_destroy method¶

これはデータベースハンドラのデストラクタのプライベートな部分です。 安全にリソースを解放できるように、IMPSET フラグがオンであるすべての dbh は破壊されなければなりません。 (上記 dbd_db_connect() でそれを設定しなければならないことに注意。)

  void dbd_db_destroy(SV* dbh, imp_dbh_t* imp_dbh)
  {
      DBIc_IMPSET_off(imp_dbh);
  }

ハンドラがまだアクティブであれば dbd_db_destroy() を呼ぶ前に、 DBI Driver.xst コードが代わりに dbd_db_disconnect() を 呼ばせるでしょう。

リターンの前に、DBI にデストラクタが既に呼ばれたことを知らせるために、 関数は IMPSET をオフに切り替えなければなりません。

A DBI handle doesn't keep references to its children. But children do keep references to their parents. So a database handle won't be DESTROY'd until all its children have been DESTROY'd. (TBT)

The dbd_db_STORE_attrib method¶

この関数は以下のものを扱います

  $dbh->{$key} = $value;

そのプロトタイプは以下のものです。

  int dbd_db_STORE_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv,
                          SV* valuesv);

あなたがすべての DBI 属性をここで扱わなってはいけないのとは反対に、 あなたはすべての属性を扱いません:これを DBI にまかせてください (唯一の例外は、AutoCommit と ChopBlanks です; これは注意してください。)

戻り値は、もしその属性を扱ったのであれば TRUE そうでなければ FALSE です。 属性を扱って何か失敗すれば、必要であれば DBI が例外を起こせるように、 dbd_drv_error() を呼ばなければなりません。 もし dbd_drv_error() が戻っても、問題があります:通常は $dbh->errstr() をチェックしないので、ユーザはそのエラーについて 分からないでしょう。

もし dbd_drv_error() が返ってきたら、処理を続けるという一般的な方法は 推奨できません。 しかし DBI 仕様で croak() することを期待しているところでさえ、 そうしているという例もあります。 (DBI の AutoCommit メソッドをご覧ください。)

属性を格納する必要があれば、プライベートなデータ構造 imp_xxx を使い、 ((HV*)SvRV(dbh) を通して)ハッシュを扱うか、プライベートな imp_data を使ってください。

前者の方が integer やポインタといった内部 C の値に向いていますし、ドライバで スピードが重要なところに向いています。 ハンドルハッシュはドライバ特有の属性を取得／設定したいかもしらない 値にと向いています。 プライベートな imp_data はハンドルに付与された追加的な SV です。 名前のないハンドル属性と考えることもができます。 通常は使われません。

The dbd_db_FETCH_attrib method¶

これは dbd_db_STORE_attrib() の逆で、以下のために必要です:

  $value = $dbh->{$key};

そのプロトタイプは以下のようになります:

  SV* dbd_db_FETCH_attrib(SV* dbh, imp_dbh_t* imp_dbh, SV* keysv);

これまでのすべてのメソッドと違って、これは値をもった SV を返します。 もし定数値でない値を返すのであれば、通常は sv_2mortal() を 実行しなければならないことに注意してください。 (定数値は &sv_undef, &sv_no, &sv_yes です。)

DBI は属性値のためのキャッシュするアルゴリズムを実装していることに 注意してください。 属性がフェッチされていると思うのであれば、dbh それ自身に格納します:

  if (cacheit) /* cache value for later DBI 'quick' fetch? */
      hv_store((HV*)SvRV(dbh), key, kl, cachesv, 0);

The dbd_st_prepare method¶

これは prepare() メソッドのプライベートな部分です。 実際にここで文を実行しては いけない ことに注意してください。 しかし、文を準備して適正チェックや同じようなことを することができます。

  int dbd_st_prepare(SV* sth, imp_sth_t* imp_sth, char* statement,
                     SV* attribs);

典型的な、単純な可能性は、何もせずにハンドルで Statement 属性を 設定した perl の prepare() コードに依存することです。 この属性はそれから dbd_st_execute() で使われます。

If the driver supports placeholders then the NUM_OF_PARAMS attribute must be set correctly by dbd_st_prepare(): (TBT)

  DBIc_NUM_PARAMS(imp_sth) = ...

できることなら、NUM_OF_FIELDS、NAME といった属性をここで 設定するべきですが、DBI はそれを要求はしません - これらは execute() が呼び出されるまで遅延します。 しかし、そうしたのであれば、ドキュメントに残しましょう。

どんな場合であっても、上記 dbd_db_connect() でやったのと同じように IMPSET フラグを設定しなければなりません:

  DBIc_IMPSET_on(imp_sth);

The dbd_st_execute method¶

ここで文が本当に実行されます:

  int dbd_st_execute(SV* sth, imp_sth_t* imp_sth);

文が繰り返し実行されることもあることに気がつかなければ ならないことに注意してください。 また二つの実行の間に finish() が呼ばれることも期待してはいけません; 従って、次のように、関数の先頭付近にコードが必要かもしれません:

  if (DBIc_ACTIVE(imp_sth))
      dbd_st_finish(h, imp_sth);

あなたのドライバがパラメータのバインドをサポートしている (そうすべきですが)のに、データベースがそうでなければ、 ここでそれをしなければならないでしょう。 それは以下のようにすることができます:

  SV *svp;
  char* statement = DBD_ATTRIB_GET_PV(h, "Statement", 9, svp, "");
  int numParam = DBIc_NUM_PARAMS(imp_sth);
  int i;

  for (i = 0; i < numParam; i++)
  {
      char* value = dbd_db_get_param(sth, imp_sth, i);
      /* It is your drivers task to implement dbd_db_get_param,    */
      /* it must be setup as a counterpart of dbd_bind_ph.         */
      /* Look for '?' and replace it with 'value'.  Difficult      */
      /* task, note that you may have question marks inside        */
      /* quotes and comments the like ...  :-(                     */
      /* See DBD::mysql for an example. (Don't look too deep into  */
      /* the example, you will notice where I was lazy ...)        */
  }

次にやることは文を本当に実行することです。

まだやっていなければ、文が正常に実行されたら、 NUM_OF_FIELDS, NAME といった属性を準備しなければならないことに 注意してください:それらは潜在的な fetchrow() の前にでも 使われるかもしれません。 DBI 内部で使われるため、特に DBI にはその文が 持っているフィールドの数を伝えなければなりません。 こうしてこの関数は通常以下のようにして終了します:

  if (isSelectStatement) {
      DBIc_NUM_FIELDS(imp_sth) = numFields;
      DBIc_ACTIVE_on(imp_sth);
  }

ACTIVE フラグを SELECT 文のためだけに設定するのは 重要なことです (or any other statements that can return many values from the database using a cursor-like mechanism)。 さらに詳しい説明は上記の dbd_db_connect() をご覧ください。

There plans for a preparse function to be provided by DBI, but this has not reached fruition yet. Meantime, if you want to know how ugly it can get, try looking at the dbd_ix_preparse() in DBD::Informix dbdimp.ec and the related functions in iustoken.c and sqltoken.c. (TBT)

The dbd_st_fetch method¶

この関数はデータの行を取り出します。 行は DBI があなたのために用意した SV の配列に格納されます。 これには二つの利点があります:それは速く(最初の fetchrow() の後に 作成する必要がないので、SV を再利用することもできます)、 DBI が bind_cols() を扱うことを保証します。

やらなければならないことは以下の通りです:

  AV* av;
  int numFields = DBIc_NUM_FIELDS(imp_sth); /* Correct, if NUM_FIELDS
      is constant for this statement. There are drivers where this is
      not the case! */
  int chopBlanks = DBIc_is(imp_sth, DBIcf_ChopBlanks);
  int i;

  if (!fetch_new_row_of_data(...)) {
      ... /* check for error or end-of-data */
      DBIc_ACTIVE_off(imp_sth); /* turn off Active flag automatically */
      return Nullav;
  }
  /* get the fbav (field buffer array value) for this row       */
  /* it is very important to only call this after you know      */
  /* that you have a row of data to return.                     */
  av = DBIc_DBISTATE(imp_sth)->get_fbav(imp_sth);
  for (i = 0; i < numFields; i++) {
      SV* sv = fetch_a_field(..., i);
      if (chopBlanks && SvOK(sv) && type_is_blank_padded(field_type[i])) {
          /*  Remove white space from end (only) of sv  */
      }
      sv_setsv(AvARRAY(av)[i], sv); /* Note: (re)use! */
  }
  return av;

SV* を返す fetch_a_field() 関数を使う必要はありません。 文字列としてデータを取り出すデータベース API 関数を使い、以下のようにする 方がもっと一般的です:

  sv_setpvn(AvARRAY(av)[i], char_ptr, char_count);

NULL 値は undef で返さなければなりません:以下のようにすることができます:

  SvOK_off(AvARRAY(av)[i]);

この関数は成功すれば DBI によって用意された AV を、そうでなければ Nullav を返します。

 *FIX ME* Discuss what happens when there's no more data to fetch.
 Are errors permitted if another fetch occurs after the first fetch
 that reports no more data. (Permitted, not required.)

If an error occurs which leaves the $sth in a state where remaining rows can't be fetched then Active should be turned off before the method returns. (TBT)

The dbd_st_finish3 method¶

$sth->finish() メソッドはデータベースが提供する行をまだ 持っていたとしても、ユーザがもう行をとりださないということを 示したいという場合、そして DBI はハンドルが破壊されたときに コードを呼ぶことができます。 背景についての詳細は DBI ドキュメントをご覧下さい。

In both circumstances, the DBI code ends up calling the dbd_st_finish3() method (if you provide a mapping for dbd_st_finish3() in dbdimp.h), or dbd_st_finish() otherwise. The difference is that dbd_st_finish3() takes a third argument which is an int with the value 1 if it is being called from a destroy() method and 0 otherwise. (TBT)

Note that DBI v1.32 and earlier test on dbd_db_finish3() to call dbd_st_finish3(); if you provide dbd_st_finish3(), either define dbd_db_finish3() too, or insist on DBI v1.33 or later. (TBT)

必要なのは sth のための Active フラグをオフに切りかえることだけです。 ドライバが sth のために ACTIVE を設定しているならば、 Driver.xst コードによって呼ばれるだけです。

概略の例:

  int dbd_st_finish3(SV* sth, imp_sth_t* imp_sth, int from_destroy) {
      if (DBIc_ACTIVE(imp_sth))
      {
          /* close cursor or equivalent action */
          DBIc_ACTIVE_off(imp_sth);
      }
      return 1;
  }

The from_destroy parameter is true if dbd_st_finish3() is being called from DESTROY() - and so the statement is about to be destroyed. For many drivers there is no point in doing anything more than turning off the Active flag in this case. (TBT)

この関数は成功すれば TRUE、そうでなければ FALSE を返しますが、 エラーの場合に回復するために出来ることはあまりありません。

The dbd_st_destroy method¶

この関数は文ハンドルのデストラクタのプライベートな部分です。

  void dbd_st_destroy(SV* sth, imp_sth_t* imp_sth) {
      ... /* any clean-up that's needed */
      DBIc_IMPSET_off(imp_sth); /* let DBI know we've done it   */
  }

dbd_st_destroy() を呼び出す前に sth が ACTIVE フラグを 設定していれば、DBI Driver.xst コードはあなたに代わって dbd_st_finish() を呼び出します。

The dbd_st_STORE_attrib and dbd_st_FETCH_attrib methods¶

これらの関数は文ハンドル用であることを除けば、上記の dbd_db_STORE() と dbd_db_FETCH() に対応します。 上記をご覧下さい。

  int dbd_st_STORE_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv,
                          SV* valuesv);
  SV* dbd_st_FETCH_attrib(SV* sth, imp_sth_t* imp_sth, SV* keysv);

The dbd_bind_ph method¶

この関数は bind_param(), bind_param_inout() そして execute() がバインド変数を伴って呼ばれるならば DBI Driver.xst コードによって内部的に使用されます。

  int dbd_bind_ph (SV *sth, imp_sth_t *imp_sth, SV *param,
                   SV *value, IV sql_type, SV *attribs,
                   int is_inout, IV maxlen);

param 引数はパラメータ番号(1,2,....) を持った IV を保持します。 value 引数はパラメータの値、sql_type はそのデータ型です。

もしあなたのドライバが bind_param_inout() をサポートしなければ maxlen を無視し、is_inout が TRUE であれば 警告(croak)しなければなりません。

もしあなたのドライバが bind_param_inout() をサポート する のであれば、 bind_param_inout() に渡されるリファレンスをデリファレンスした 後、 value は SV であることに注意しなければなりません。

簡単なデータベースのドライバでは、関数は例えばパラメータ配列に格納し、後の dbd_st_execute() の中で使うでしょう。 例として DBD::mysql ドライバをご覧下さい。

Implementing bind_param_inout support¶

To provide support for parameters bound by reference rather than by value, the driver must do a number of things. First, and most importantly, it must note the references and stash them in its own driver structure. Secondly, when a value is bound to a column, the driver must discard any previous reference bound to the column. On each execute, the driver must evaluate the references and internally bind the values resulting from the references. This is only applicable if the user writes: (TBT)

  $sth->execute;

If the user writes: (TBT)

  $sth->execute(@values);

then DBI automatically calls the binding code for each element of @values. These calls are indistinguishable from explicit user calls to bind_param(). (TBT)

C/XS 版の Makefile.PL¶

The Makefile.PL file for a C/XS driver is similar to the code needed for a pure Perl driver, but there are a number of extra bits of information needed by the build system. (TBT)

For example, the attributes list passed to WriteMakefile() needs to specify the object files that need to be compiled and built into the shared object (DLL). This is often, but not necessarily, just dbdimp.o (unless that should be dbdimp.obj because you're building on MS Windows). (TBT)

Note that you can reliably determine the extension of the object files from the $Config{obj_ext} values, and there are many other useful pieces of configuration information lurking in that hash. You get access to it with: (TBT)

    use Config;

書く必要のないメソッド¶

DBI コードは DBI->function() といった書き方を使って アクセスされるメソッドの多くを実装しています; 唯一の例外は DBI->connect() と DBI->data_sources() で、 これはドライバからのサポートを必要とします。

DBI コードは以下に書かれているドライバ、データベース、そして 文関数を実装しています。これらは DBD ドライバの作者は書く 必要がありません。

$dbh->do()

The default implementation of this function prepares, executes and destroys the statement. This can be replaced if there is a better way to implement this, such as EXECUTE IMMEDIATE which can sometimes be used if there are no parameters.

この関数のデフォルトの実装はその文を準備(prepare)し、 実行(execute)し、破壊(destroy)します。 もしパラメータがなければ場合によっては使うことが出来る EXECUTE IMMEDIATE のように、実装するのによりよい方法があれば、これを 置きかえることができます。

$h->errstr()

$h->err()

$h->state()

$h->trace()

The DBD driver does not need to worry about these routines at all.

これらのルーチンについて、DBD ドライバはまったく心配する必要がありません。

$h->{ChopBlanks}

This attribute needs to be honored during fetch() operations, but does not need to be handled by the attribute handling code.

この属性は fetch() 操作の間は気にしなければなりませんが、属性を 取り扱う部分で扱われる必要はありません。

$h->{RaiseError}

The DBD driver does not need to worry about this attribute at all.

DBD ドライバはこの属性についてまったく心配する必要がありません。

$h->{PrintError}

The DBD driver does not need to worry about this attribute at all.

DBD ドライバはこの属性についてまったく心配する必要がありません。

$sth->bind_col()

Assuming the driver uses the DBIc_DBISTATE(imp_xxh)->get_fbav() function (C drivers, see below), or the $sth->_set_fbav($data) method (Perl drivers) the driver does not need to do anything about this routine.

DBIc_DBISTATE(imp_xxh)->get_fbav() 関数(Cドライバ、以下を参照)、 または $sth->_set_fbav($data) メソッド(Perlドライバ)を使う ドライバであれば、ドライバはこのルーチンについて何もする必要がありません。

$sth->bind_columns()

Regardless of whether the driver uses DBIc_DBISTATE(imp_xxh)->get_fbav(), the driver does not need to do anything about this routine as it simply iteratively calls $sth->bind_col().

ドライバが DBIc_DBISTATE(imp_xxh)->get_fbav() を 使っているかどうかに関らず、それが単に内部的に $sth->bind_col() を呼ぶので、ドライバはこのルーチンについて 何もする必要がありません。

DBI コードはデフォルトの実装がそのドライバにとって正しくないのでなければ、 DBD ドライバの作者がそれを書かなくて済むように、以下の関数のデフォルトを 実装しています。

$dbh->quote()

This should only be written if the database does not accept the ANSI SQL standard for quoting strings, with the string enclosed in single quotes and any embedded single quotes replaced by two consecutive single quotes.

データベースがクォートされた文字列のための、シングルクォートで囲まれ、 埋め込まれたシングルクォートは一つのシングルクォートにつき二つの シングルクォートで置き換えるという、ANSI SQL標準を受け取らない場合にのみ、 書かれる必要があります。

For the two argument form of quote, you need to implement the type_info() method to provide the information that quote needs.

二つのクォートの形式の引数のために、クォートが必要とする情報を 提供するための type_info() メソッドを実装する必要があります。

$dbh->ping()

This should be implemented as a simple efficient way to determine whether the connection to the database is still alive. Typically code like this:

データベースへの接続がまだ生きているかどうかを判定するための単純な 効率的な方法として実装されなければなりません。 典型的には以下のようになります:

  sub ping {
      my $dbh = shift;
      $sth = $dbh->prepare_cached(q{
          select * from A_TABLE_NAME where 1=0
      }) or return 0;
      $sth->execute or return 0;
      $sth->finish;
      return 1;
  }

where A_TABLE_NAME is the name of a table that always exists (such as a database system catalogue).

A_TABLE_NAME は(データベースのシステムカタログのような)常に存在する テーブルの名前です

メタデータメソッド¶

The exposition above ignores the DBI MetaData methods. The metadata methods are all associated with a database handle. (TBT)

DBI::DBD::Metadata を使う¶

The DBI::DBD::Metadata module is a good semi-automatic way for the developer of a DBD module to write the get_info() and type_info() functions quickly and accurately. (TBT)

Generating the get_info method¶

Prior to DBI v1.33, this existed as the method write_getinfo_pm() in the DBI::DBD module. From DBI v1.33, it exists as the method write_getinfo_pm() in the DBI::DBD::Metadata module. This discussion assumes you have DBI v1.33 or later. (TBT)

You examine the documentation for write_getinfo_pm() using: (TBT)

    perldoc DBI::DBD::Metadata

To use it, you need a Perl DBI driver for your database which implements the get_info() method. In practice, this means you need to install DBD::ODBC, an ODBC driver manager, and an ODBC driver for your database. (TBT)

With the pre-requisites in place, you might type: (TBT)

    perl -MDBI::DBD::Metadata -we \
       "write_getinfo_pm (qw{ dbi:ODBC:foo_db username password Driver })"

The procedure writes to standard output the code that should be added to your Driver.pm file and the code that should be written to lib/DBD/Driver/GetInfo.pm. (TBT)

You should review the output to ensure that it is sensible. (TBT)

Generating the type_info method¶

Given the idea of the write_getinfo_pm() method, it was not hard to devise a parallel method, write_typeinfo_pm(), which does the analogous job for the DBI type_info_all() metadata method. The write_typeinfo_pm() method was added to DBI v1.33. (TBT)

You examine the documentation for write_typeinfo_pm() using: (TBT)

    perldoc DBI::DBD::Metadata

The setup is exactly analogous to the mechanism described in "Generating the get_info method". (TBT)

With the pre-requisites in place, you might type: (TBT)

    perl -MDBI::DBD::Metadata -we \
       "write_typeinfo (qw{ dbi:ODBC:foo_db username password Driver })"

The procedure writes to standard output the code that should be added to your Driver.pm file and the code that should be written to lib/DBD/Driver/TypeInfo.pm. (TBT)

You should review the output to ensure that it is sensible. (TBT)

DBD::Driver::db::get_info を書く¶

If you use the DBI::DBD::Metadata module, then the code you need is generated for you. (TBT)

If you decide not to use the DBI::DBD::Metadata module, you should probably borrow the code from a driver that has done so (eg DBD::Informix from version 1.05 onwards) and crib the code from there, or look at the code that generates that module and follow that. The method in Driver.pm will be very simple; the method in lib/DBD/Driver/GetInfo.pm is not very much more complex unless your DBMS itself is much more complex. (TBT)

Note that some of the DBI utility methods rely on information from the get_info() method to perform their operations correctly. See, for example, the quote_identifier() and quote methods, discussed below. (TBT)

DBD::Driver::db::type_info_all を書く¶

If you use the DBI::DBD::Metadata module, then the code you need is generated for you. (TBT)

If you decide not to use the DBI::DBD::Metadata module, you should probably borrow the code from a driver that has done so (eg DBD::Informix from version 1.05 onwards) and crib the code from there, or look at the code that generates that module and follow that. The method in Driver.pm will be very simple; the method in lib/DBD/Driver/TypeInfo.pm is not very much more complex unless your DBMS itself is much more complex. (TBT)

DBD::Driver::db::type_info を書く¶

The guidelines on writing this method are still not really clear. No sample implementation is available. (TBT)

DBD::Driver::db::table_info を書く¶

 *FIX ME* The guidelines on writing this method have not been written yet.
 No sample implementation is available.

DBD::Driver::db::column_info を書く¶

 *FIX ME* The guidelines on writing this method have not been written yet.
 No sample implementation is available.

DBD::Driver::db::primary_key_info を書く¶

 *FIX ME* The guidelines on writing this method have not been written yet.
 No sample implementation is available.

DBD::Driver::db::primary_key を書く¶

 *FIX ME* The guidelines on writing this method have not been written yet.
 No sample implementation is available.

DBD::Driver::db::foreign_key_info を書く¶

 *FIX ME* The guidelines on writing this method have not been written yet.
 No sample implementation is available.

DBD::Driver::db::tables を書く¶

This method generates an array of names in a format suitable for being embedded in SQL statements in places where a table name is expected. (TBT)

If your database hews close enough to the SQL standard or if you have implemented an appropriate table_info() function and and the appropriate quote_identifier() function, then the DBI default version of this method will work for your driver too. (TBT)

Otherwise, you have to write a function yourself, such as: (TBT)

    sub tables
    {
        my($dbh, $cat, $sch, $tab, $typ) = @_;
        my(@res);
        my($sth) = $dbh->table_info($cat, $sch, $tab, $typ);
        my(@arr);
        while (@arr = $sth->fetchrow_array)
        {
            push @res, $dbh->quote_identifier($arr[0], $arr[1], $arr[2]);
        }
        return @res;
    }

See also the default implementation in DBI.pm. (TBT)

DBD::Driver::db::quote を書く¶

This method takes a value and converts it into a string suitable for embedding in an SQL statement as a string literal. (TBT)

If your DBMS accepts the SQL standard notation for strings (single quotes around the string as a whole with any embedded single quotes doubled up), then you do not need to write this method as DBI provides a default method that does it for you. (TBT)

If your DBMS uses an alternative notation or escape mechanism, then you need to provide an equivalent function. For example, suppose your DBMS used C notation with double quotes around the string and backslashes escaping both double quotes and backslashes themselves. Then you might write the function as: (TBT)

    sub quote
    {
        my($dbh, $str) = @_;
        $str =~ s/["\\]/\\$&/gmo;
        return qq{"$str"};
    }

Handling newlines and other control characters is left as an exercise for the reader. (TBT)

This sample method ignores the $data_type indicator which is the optional second argument to the method. (TBT)

DBD::Driver::db::quote_identifier を書く¶

This method is called to ensure that the name of the given table (or other database object) can be embedded into an SQL statement without danger of misinterpretation. The result string should be usable in the text of an SQL statement as the identifier for a table. (TBT)

If your DBMS accepts the SQL standard notation for quoted identifiers (which uses double quotes around the identifier as a whole, with any embedded double quotes doubled up) and accepts "schema"."identifier" (and "catalog"."schema"."identifier" when a catalog is specified), then you do not need to write this method as DBI provides a default method that does it for you. (TBT)

In fact, even if your DBMS does not handle exactly that notation but you have implemented the get_info() method and it gives the correct responses, then it will work for you. If your database is fussier, then you need to implement your own version of the function. (TBT)

For example, DBD::Informix has to deal with an environment variable DELIMIDENT. If it is not set, then the DBMS treats names enclosed in double quotes as strings rather than names, which is usually a syntax error. Additionally, the catalog portion of the name is separated from the schema and table by a different delimiter (colon instead of dot), and the catalog portion is never enclosed in quotes. (Fortunately, valid strings for the catalog will never contain weird characters that might need to be escaped, unless you count dots, dashes, slashes and at-signs as weird.) Finally, an Informix database can contain objects that cannot be accessed because they were created by a user with the DELIMIDENT environment variable set, but the current user does not have it set. By design choice, the quote_identifier() method encloses those identifiers in double quotes anyway, which generally triggers a syntax error, and the metadata methods which generate lists of tables etc omit those identifiers from the result sets. (TBT)

    sub quote_identifier
    {
        my($dbh, $cat, $sch, $obj) = @_;
        my($rv) = "";
        my($qq) = (defined $ENV{DELIMIDENT}) ? '"' : '';
        $rv .= qq{$cat:} if (defined $cat);
        if (defined $sch)
        {
            if ($sch !~ m/^\w+$/o)
            {
                $qq = '"';
                $sch =~ s/$qq/$qq$qq/gm;
            }
            $rv .= qq{$qq$sch$qq.};
        }
        if (defined $obj)
        {
            if ($obj !~ m/^\w+$/o)
            {
                $qq = '"';
                $obj =~ s/$qq/$qq$qq/gm;
            }
            $rv .= qq{$qq$obj$qq};
        }
        return $rv;
    }

Handling newlines and other control characters is left as an exercise for the reader. (TBT)

Note that there is an optional fourth parameter to this function which is a reference to a hash of attributes; this sample implementation ignores that. (TBT)

This sample implementation also ignores the single-argument variant of the method. (TBT)

トレース¶

Tracing in DBI is controlled with a combination of a trace level and a set of flags which together are known as the trace settings. The trace settings are stored in a single integer and divided into levels and flags by a set of masks (DBIc_TRACE_LEVEL_MASK and DBIc_TRACE_FLAGS_MASK). (TBT)

Each handle has it's own trace settings and so does the DBI. When you call a method the DBI merges the handles settings into its own for the duration of the call: the trace flags of the handle are OR'd into the trace flags of the DBI, and if the handle has a higher trace level then the DBI trace level is raised to match it. The previous DBI trace settings are restored when the called method returns. (TBT)

トレースレベル¶

The trace level is the first 4 bits of the trace settings (masked by DBIc_TRACE_FLAGS_MASK) and represents trace levels of 1 to 15. Do not output anything at trace levels less than 3 as they are reserved for DBI. (TBT)

For advice on what to output at each level see "Trace Levels" in DBI. (TBT)

To test for a trace level you can use the DBIc_TRACE_LEVEL macro like this: (TBT)

  if (DBIc_TRACE_LEVEL(imp_xxh) >= 2) {
      PerlIO_printf(DBIc_LOGPIO(imp_xxh), "foobar");
  }

Also note the use of PerlIO_printf which you should always use for tracing and never the C stdio.h I/O functions. (TBT)

トレースフラグ¶

Trace flags are used to enable tracing of specific activities within the DBI and drivers. The DBI defines some trace flags and drivers can define others. DBI trace flag names begin with a capital letter and driver specific names begin with a lowercase letter. For a list of DBI defined trace flags see "Trace Flags" in DBI. (TBT)

If you want to use private trace flags you'll probably want to be able to set them by name. Drivers are expected to override the parse_trace_flag (note the singular) and check if $trace_flag_name is a driver specific trace flags and, if not, then call the DBIs default parse_trace_flag(). To do that you'll need to define a parse_trace_flag() method like this: (TBT)

  sub parse_trace_flag {
      my ($h, $name) = @_;
      return 0x01000000 if $name eq 'foo';
      return 0x02000000 if $name eq 'bar';
      return 0x04000000 if $name eq 'baz';
      return 0x08000000 if $name eq 'boo';
      return 0x10000000 if $name eq 'bop';
      return $h->SUPER::parse_trace_flag($name);
  }

All private flag names must be lowercase, and all private flags must be in the top 8 of the 32 bits of DBIc_TRACE_FLAGS(imp) i.e., 0xFF000000. (TBT)

If you've defined a parse_trace_flag() method in ::db you'll also want it in ::st, so just alias it in: (TBT)

  *parse_trace_flag = \&DBD::foo:db::parse_trace_flag;

You may want to act on the current 'SQL' trace flag that DBI defines to output SQL prepared/executed as DBI currently does not do SQL tracing. (TBT)

トレースマクロ¶

Access to the trace level and trace flags is via a set of macros. (TBT)

  DBIc_TRACE_SETTINGS(imp) returns the trace settings
  DBIc_TRACE_LEVEL(imp) returns the trace level
  DBIc_TRACE_FLAGS(imp) returns the trace flags
  DBIc_TRACE(imp, flags, flaglevel, level)

  e.g.,

  DBIc_TRACE(imp, 0, 0, 4)
    if level >= 4

  DBIc_TRACE(imp, DBDtf_FOO, 2, 4)
    if tracing DBDtf_FOO & level>=2 or level>=4

  DBIc_TRACE(imp, DBDtf_FOO, 2, 0)
    as above but never trace just due to level

古い Perl インターフェースのためのエミュレーション層を書く¶

考え方については、(DBD::Oracle と一緒に提供される)Oraperl.pm、 (DBD::Ingres と一緒に提供される)Ingperl.pm そして対応する dbdimp.c ファイルを勉強してください。

エミュレーションコードは各接続について $dbh->{CompatMode} = 1; を 設定していることに注意してください。 これはドライバの内部でそれらを扱うときに、古いインターフェースと互換性を もった動きを実装できるようにするためです。

エミュレーション perl 変数の設定¶

例えば ingperl は変数 $sql_rowcount を持っています。 これを Ingperl.pm のなかで手動で更新するよりは、C コードで やってしまう方がむしろ速いでしょう。 dbd_init() では:

  sql_rowcount = perl_get_sv("Ingperl::sql_rowcount", GV_ADDMULTI);

対応する場所は以下のようにします:

  if (DBIc_COMPAT(imp_sth))     /* only do this for compatibility mode handles */
      sv_setiv(sql_rowcount, the_row_count);

その他の様々な情報¶

imp_xyz_t 型¶

すべてのハンドルはプライベートがいっぱい入った対応する C 構造体を持ちます。 このデータの一部は DBI のために予約されています(以下の DBIc マクロを 使うのを除いて)、一部はあなたのためです。 例として上記の dbdimp.h の説明をご覧下さい。 dbdimp.c のほとんどの関数はハンドル xyz と imp_xyz へのポインタを 渡されます。 しかしながら、まれに以下のマクロを使うこともできます。

D_imp_dbh(dbh)

Given a function argument dbh, declare a variable imp_dbh and initialize it with a pointer to the handles private data. Note: This must be a part of the function header, because it declares a variable.

関数引数 dbh 変数を与えられ、imp_dbh を宣言し、それをハンドルへの プライベートデータへのポインタで初期化します。 注意:これは関数ヘッダの一部でなければなりません、というのも変数を 宣言するからです。

D_imp_sth(sth)

Likewise for statement handles.

文ハンドルと同様です。

D_imp_xxx(h)

Given any handle, declare a variable imp_xxx and initialize it with a pointer to the handles private data. It is safe, for example, to cast imp_xxx to imp_dbh_t*, if DBIc_TYPE(imp_xxx) == DBIt_DB. (You can also call sv_derived_from(h, "DBI::db"), but that's much slower.)

すべてのハンドルを与えられ、変数 imp_xxx を宣言し、それをハンドルの プライベートデータへのポインタで初期化します。 例えば、DBIc_TYPE(imp_xxx) == DBIt_DB であれば、imp_xxx を imp_dbh_t* にキャストするのは安全です (sv_derived_from(h, "DBI::db") を呼ぶこともできますが、それはもっと 時間がかかります)

D_imp_dbh_from_sth

Given a imp_sth, declare a variable imp_dbh and initialize it with a pointer to the parent database handle's implementors structure.

imp_sth を与えられ、変数 imp_dbh を宣言し、それを 親データベースハンドルの実装構造へのポインタで初期化します。

DBIc_IMPSET_on を使う¶

ハンドルを初期化するドライバコードは、後片付けコードが 呼ばれなければならないような状態になったらすぐに、DBIc_IMPSET_on() を 使わなければなりません。 これが発生するときはドライバコードによって判定されます。

これを呼び出すのに失敗するとデータ構造がおかしくなるかもしれません。

例えば DBD::Informix はドライバで、リンクされたデータベースハンドルの リストを、そして各ハンドルでは状態のリンクされたリスト管理します。 一度リンクされたリストに文が追加されると、片付けられるのは (リストから削除される)のはとても重要です。 DBIc_IMPSET_on() が呼ばれるのが遅すぎると、あらゆる種類の障害を 起こす可能性があります。

DBIc_is(), DBIc_has(), DBIc_on() and DBIc_off() を使う¶

その昔、以下のようなマクロを通すのが内部 DBI ブール値のフラグ／属性を扱う 唯一の方法でした:

  DBIc_WARN       DBIc_WARN_on        DBIc_WARN_off
  DBIc_COMPAT     DBIc_COMPAT_on      DBIc_COMPAT_off

これらのそれぞれはimp_xxhポインタを引数として取ります。

その後、ChopBlanks, RaiseError, PrintError といった新しく 加えられた属性は、マクロのフルセットを持ちません。 これらを扱うために認められている方法はいまや四つのマクロです:

  DBIc_is(imp, flag)
  DBIc_has(imp, flag)       an alias for DBIc_is
  DBIc_on(imp, flag)
  DBIc_off(imp, flag)
  DBIc_set(imp, flag, on)   set if on is true, else clear

したがってマクロの DBIc_XXXXX の種類はいまやほとんど止めるように いわれており、古いドライバはおそらくしばらくの間は そうするでしょうけれども、新しいドライバはそれらを使うことを避けるべきです。 しかしながら...

重要な例外があります。 ACTIVE と IMPSET フラグは DBIc_ACTIVE_on() と DBIc_IMPSET_on() マクロによって設定され、DBIc_ACTIVE_off() と DBIc_IMPSET_off() に よって解除なければなりません。

get_fbav() メソッドを使う¶

これは C/XS ドライバにとって重要です。

DBI の仕様でドキュメント化されている $sth->bind_col() と $sth->bind_columns() はドライバの作者によって実行される 必要はありません; というのも DBI が代りに面倒を見てくれるからです。

しかしカラムのバインドが機能することを保証する鍵は、データの行を取り出す DBIc_DBISTATE(imp_xxh)->get_fbav() 関数を呼び出すことです。

これは AV を返し、そして AV の各要素は返されるデータを持つように 設定されるべき SV を持っています。

ピュア Perl の等価物は、ドライバの部分で記述される $sth->_set_fbav($data) メソッドです。

文字列を SQL 型による Perl 型にキャストする¶

DBI from 1.611 (and DBIXS_REVISION 13606) defines the sql_type_cast_svpv method which may be used to cast a string representation of a value to a more specific Perl type based on a SQL type. You should consider using this method when processing bound column data as it provides some support for the TYPE bind_col attribute which is rarely used in drivers. (TBT)

  int sql_type_cast_svpv(pTHX_ SV *sv, int sql_type, U32 flags, void *v)

sv is what you would like cast, sql_type is one of the DBI defined SQL types (e.g., SQL_INTEGER) and flags is a bitmask as follows: (TBT)

DBIstcf_STRICT

If set this indicates you want an error state returned if the cast cannot be performed.

If set this indicates you want an error state returned if the cast cannot be performed. (TBT)

DBIstcf_DISCARD_STRING

If set and the pv portion of the sv is cast then this will cause sv's pv to be freed up.

If set and the pv portion of the sv is cast then this will cause sv's pv to be freed up. (TBT)

sql_type_cast_svpv returns the following states: (TBT)

 -2 sql_type is not handled - sv not changed
 -1 sv is undef, sv not changed
  0 sv could not be cast cleanly and DBIstcf_STRICT was specified
  1 sv could not be case cleanly and DBIstcf_STRICT was not specified
  2 sv was cast ok

The current implementation of sql_type_cast_svpv supports SQL_INTEGER, SQL_DOUBLE and SQL_NUMERIC. SQL_INTEGER uses sv_2iv and hence may set IV, UV or NV depending on the number. SQL_DOUBLE uses sv_2nv so may set NV and SQL_NUMERIC will set IV or UV or NV. (TBT)

DBIstcf_STRICT should be implemented as the StrictlyTyped attribute and DBIstcf_DISCARD_STRING implemented as the DiscardString attribute to the bind_col method and both default to off. (TBT)

See DBD::Oracle for an example of how this is used. (TBT)

DBI ドライバのサブクラス化¶

これは完全にオープンな議題です。 DBD::File ドライバが証明しているように、それは可能です。 しかし思っているほど簡単ではないかもしれません。

(このトピックは DBI のサブクラス化とは違うことに注意してください。 その例については、DBI と一緒に提供される t/subclass.t ファイルを ご覧下さい。)

主な問題は、connect() や prepare() メソッドが返す dbh のそして sth は DBD::Driver::db や DBD::Driver::st の インスタンスではありません; そこから派生したものですらありません。 その代わりに DBD::db や DBD::st クラスまたは派生したサブクラスの インスタンスです。 このため、もし mymethod() を書いて、以下のようにすると

  $dbh->mymethod()

autoloader は DBI::db パッケージでそのメソッドを探します。 もちろん代りに以下のようにすることもできます

  $dbh->func('mymethod')

そして、もし mymethod() が継承されていたとしても、これは本当に 機能しますが、追加的な機能はありません。@ISA を設定することだけでは 不充分です。

メソッドの上書き¶

最初の問題は、connect() メソッドにはサブクラスの考えがないことです。 例えば同じファイルにベースとなるクラスとサブクラスを 実行することはできません:install_driver() メソッドが以下のようにしたい。

  require DBD::Driver;

特に、あなたのサブクラスは DBIの視点からは別のドライバに なる べき です。 そしてドライバハンドルを共有することはできません。

それはもちろん大した問題ではありません。 ベースクラスの connect() メソッドを継承することできるはずです。 しかし以下のようなことをしないかぎり、簡単にメソッドを 上書きすることはできません。 DBD::CSV から引用すると:

  sub connect ($$;$$$) {
      my ($drh, $dbname, $user, $auth, $attr) = @_;

      my $this = $drh->DBD::File::dr::connect($dbname, $user, $auth, $attr);
      if (!exists($this->{csv_tables})) {
          $this->{csv_tables} = {};
      }

      $this;
  }

以下のような

  $drh->SUPER::connect($dbname, $user, $auth, $attr);

通常にOO環境でおこなうようにできないことに注意してください; というのも $drh は DBI::dr のインスタンスだからです。 そして DBD::File の connect() メソッドはサブクラスの属性を扱うことが 出来ることも注意してください。 上記のピュア Perl ドライバの説明をご覧下さい。

上記の方法で常にスーパークラスメソッドを呼ぶことは非常に重要です。 しかしながら、それはそうすべきです。

属性の扱い¶

幸いなことに DBI 仕様は簡単でありながら、パフォーマンスのよい属性を 取り扱う方法を可能にしています。 この考え方は、すべてのドライバはプライベートはメソッドのためには 接頭語 driver_ を使うという約束を基本にしています。 このため属性をスーパークラスに渡すのか、そうでないのかは常に明確です。 例えば DBD::CSV クラスからの STORE() メソッドについて考えてみてください:

  sub STORE {
      my ($dbh, $attr, $val) = @_;
      if ($attr !~ /^driver_/) {
          return $dbh->DBD::File::db::STORE($attr, $val);
      }
      if ($attr eq 'driver_foo') {
      ...
  }

作者¶

Jonathan Leffler <jleffler@us.ibm.com> (previously <jleffler@informix.com>), Jochen Wiedmann <joe@ispsoft.de>, Steffen Goeldner <sgoeldner@cpan.org>, and Tim Bunce <dbi-users@perl.org>.