home *** CD-ROM | disk | FTP | other *** search
/ isnet Internet / Isnet Internet CD.iso / prog / hiz / 09 / 09.exe / adynware.exe / perl / lib / site / DBI / DBD.pm next >
Encoding:
Perl POD Document  |  1999-12-28  |  12.5 KB  |  450 lines

  1.  
  2.  
  3. =head1 NAME
  4.  
  5. DBI::DBD - DBD Driver Writer's Guide (draft)
  6.  
  7. =head1 SYNOPSIS
  8.  
  9.     perldoc DBI::FAQ
  10.  
  11. =head1 VERSION and VOLATILITY
  12.  
  13.     $Revision: 1.5 $
  14.     $Date: 1997/07/22 23:17:50 $
  15.  
  16. This document is very much a minimal draft which will need to be revised
  17. frequently (and extensively).
  18.  
  19. The changes will occur both because the DBI specification is changing
  20. and hence the requirements on DBD drivers change, and because feedback
  21. from people reading this document will suggest improvements to it.
  22.  
  23. Please read the DBI documentation first and fully, including the DBI FAQ.
  24.  
  25. =head1 DESCRIPTION
  26.  
  27. This document is primarily intended to help people writing new
  28. database drivers for the Perl Database Interface (Perl DBI).
  29. It may also help others interested in discovering why the internals of
  30. a DBD driver are written the way they are.
  31.  
  32. This is a guide.  Few (if any) of the statements in it are completely
  33. authoritative under all possible circumstances.  This means you will
  34. need to use judgement in applying the guidelines in this document.
  35.  
  36. =head1 REGISTERING A NEW DRIVER
  37.  
  38. Before writing a new driver, it is in your interests to find out
  39. whether there already is a driver for your database.
  40. If there is such a driver, it should be easier to make use of it than
  41. to write your own.
  42.  
  43.     [...More info TBS...]
  44.  
  45. =head2 Locating drivers
  46.  
  47. The primary web-site for locating Perl software is
  48. L<http://www.perl.com/CPAN>.
  49. You should look under the various modules listings for the software
  50. you are after.
  51. Two of the main pages you should look at are:
  52.  
  53.   http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces/DBI
  54.  
  55.   http://www.perl.org/CPAN/modules/by-category/07_Database_Interfaces/DBD
  56.  
  57. The primary web-site for locating DBI software and information is
  58. http://www.hermetica.com/technologia/DBI.
  59.  
  60. =head2 DBI Mailing Lists
  61.  
  62. There are 2 main and one auxilliary mailing lists for people working
  63. with DBI.  The primary lists are dbi-users@fugue.com for general users
  64. of DBI and DBD drivers, and dbi-dev@fugue.com mainly for DBD driver
  65. writers (don't join the dbi-dev list unless you have a good reason).
  66. The auxilliary list is dbi-announce@fugue.com for announcing new
  67. releases of DBI or DBD drivers.
  68.  
  69. You can join these lists by accessing the web-site
  70. L<http://www.fugue.com/dbi>.
  71. If you have not got web access, you may send a request to
  72. dbi-request@fugue.com, but this will be handled manually when the
  73. people in charge find the time to deal with it.  Use the web-site.
  74.  
  75. You should also consider monitoring the comp.lang.perl newsgroups.
  76.  
  77. =head2 Registering a new driver
  78.  
  79. Before going through any official registration process, you will need
  80. to establish that there is no driver already in the works.
  81. You'll do that by asking the DBI mailing lists whether there is such a
  82. driver available, or whether anybody is working on one.
  83.  
  84.     [...More info TBS...]
  85.  
  86. =head1 CREATING A NEW DRIVER
  87.  
  88. Creating a new driver from scratch will always be a daunting task.
  89. You can and should greatly simplify your task by taking a good
  90. reference driver implementation and modifying that to match the
  91. database product for which you are writing a driver.
  92.  
  93. The de facto reference driver is the one for DBD::Oracle, written by
  94. Tim Bunce who is also the author of the DBI package. The DBD::Oracle
  95. module is a good example of a driver implemented around a C-level API.
  96.  
  97. The DBD::ODBC module is also a good reference for a driver implemented
  98. around an SQL CLI or ODBC based C-level API.
  99.  
  100. The DBD::Informix driver is a good reference for a driver implemented
  101. using 'embedded SQL'.
  102.  
  103.     [...More info TBS...]
  104.  
  105. =head1 REQUIREMENTS ON A DRIVER
  106.  
  107. T.B.S.
  108.  
  109. =head1 CODE TO BE WRITTEN
  110.  
  111. A minimal driver will contain 7 files plus some tests.
  112. Assuming that your driver is called DBD::Driver, these files are:
  113.  
  114. =over 4
  115.  
  116. =item Driver.pm
  117.  
  118. =item Driver.xs
  119.  
  120. =item Driver.h
  121.  
  122. =item dbdimp.h
  123.  
  124. =item dbdimp.c
  125.  
  126. =item Makefile.PL
  127.  
  128. =item README
  129.  
  130. =item MANIFEST
  131.  
  132. =back
  133.  
  134. =head2 Driver.pm
  135.  
  136. The Driver.pm file defines the Perl module DBD::Driver for your driver.
  137. It will define a package DBD::Driver along with some version
  138. information, some variable definitions, and a function driver() which
  139. will have a more or less standard structure.
  140.  
  141. It will also define a package DBD::Driver::dr (which will define the
  142. driver() and connect() methods), and a package DBD::Driver::db (which
  143. will define a function prepare() etc), and a package DBD::Driver::st.
  144.  
  145. Each of these classes may define a function errstr(), which will
  146. simply relay its arguments to DBD::Driver::errstr() and implicitly
  147. return the value from DBD::Driver::errstr().  The DBD::Driver::errstr()
  148. function is actually defined in Driver.xs.
  149.  
  150. The Driver.pm file will also contain the documentation specific to
  151. DBD::Driver in the format used by perldoc.
  152.  
  153. =head2 Driver.xs
  154.  
  155. Driver.xs should look like this:
  156.  
  157.  
  158.   DBISTATE_DECLARE;
  159.  
  160.   MODULE = DBD::Driver    PACKAGE = DBD::Driver
  161.  
  162.   INCLUDE: Driver.xsi
  163.  
  164.   MODULE = DBD::Driver    PACKAGE = DBD::Driver::st
  165.  
  166.  
  167. =head2 Driver.h
  168.  
  169. Driver.h should look like this:
  170.  
  171.  
  172.  
  173.  
  174.  
  175.  
  176. =head2 Implementation header dbdimp.h
  177.  
  178. T.B.S
  179.  
  180. =head2 Implementation source dbdimp.c
  181.  
  182. T.B.S
  183.  
  184. =head2 Makefile.PL
  185.  
  186. Driver.xs should look like this:
  187.  
  188.   use 5.004;
  189.   use ExtUtils::MakeMaker;
  190.   use Config;
  191.   use strict;
  192.   use DBI 0.86;
  193.   use DBI::DBD;
  194.  
  195.   my %opts = (
  196.     NAME => 'DBD::Driver',
  197.     VERSION_FROM => 'Driver.pm',
  198.     clean => { FILES=> 'Driver.xsi' },
  199.     dist  => { DIST_DEFAULT=> 'clean distcheck disttest ci tardist',
  200.                 PREOP => '$(MAKE) -f Makefile.old distdir' },
  201.  
  202. Add other options here as needed. See ExtUtils::MakeMaker for more info.
  203.  
  204.   );
  205.  
  206.   WriteMakefile(%opts);
  207.  
  208.   exit(0);
  209.  
  210.   sub MY::postamble {
  211.     return dbd_postamble();
  212.   }
  213.  
  214.  
  215. =head2 README file
  216.  
  217. The README file should describe the pre-requisites for the build
  218. process, the actual build process, and how to report errors.
  219. Note that users will find ways of breaking the driver build and test
  220. process which you would never dream possible.
  221. Therefore, you need to write this document defensively and precisely.
  222. Also, it is in your interests to ensure that your tests work as widely
  223. as possible.
  224. As always, use the README from one of the established drivers as a
  225. basis for your own.
  226.  
  227.     [...More info TBS...]
  228.  
  229. =head2 MANIFEST
  230.  
  231. The MANIFEST will be used by the Makefile'd dist target to build the
  232. distribution tar file that is uploaded to CPAN.
  233.  
  234. =head2 Tests
  235.  
  236. The test process should conform as closely as possibly to the Perl
  237. standard test harness.
  238.  
  239. In particular, most of the tests should be run in the t sub-directory,
  240. and should simply produce an 'ok' when run under 'make test'.
  241. For details on how this is done, see the Camel book and the section in
  242. Chapter 7, "The Standard Perl Library" on Test::Harness.
  243.  
  244. The tests may need to adapt to the type of database which is being
  245. used for testing, and to the privileges of the user testing the
  246. driver.
  247. The DBD::Informix test code has to adapt in a number of places to the
  248. type of database to which it is connected as different Informix
  249. databases have different capabilities.
  250.  
  251.     [...More info TBS...]
  252.  
  253. =head1 METHODS WHICH DO NOT NEED TO BE WRITTEN
  254.  
  255. The DBI code implements the majority of the methods which are
  256. accessed using the notation DBI->function(), the only exceptions being
  257. DBI->connect() and DBI->data_sources() which require support from the
  258. driver.
  259.  
  260. =over 4
  261.  
  262. =item DBI->available_drivers()
  263.  
  264. =item DBI->neat_list()
  265.  
  266. =item DBI->neat()
  267.  
  268. =item DBI->dump_results()
  269.  
  270. =item DBI->func()
  271.  
  272. =back
  273.  
  274. The DBI code implements the following documented driver, database and
  275. statement functions which do not need to be written by the DBD driver
  276. writer.
  277.  
  278. =over 4
  279.  
  280. =item $dbh->do()
  281.  
  282. The default implementation of this function prepares, executes and
  283. destroys the statement.  This should be replaced if there is a better
  284. way to implement this, such as EXECUTE IMMEDIATE.
  285.  
  286. =item $h->err()
  287.  
  288. See the comments on $h->errstr() below.
  289.  
  290. =item $h->state()
  291.  
  292. See the comments on $h->errstr() below.
  293.  
  294. =item $h->trace()
  295.  
  296. The DBD driver does not need to worry about this routine at all.
  297.  
  298. =item $h->{ChopBlanks}
  299.  
  300. This attribute needs to be honured during fetch operations, but does
  301. not need to be handled by the attribute handling code.
  302.  
  303. =item $h->{RaiseError}
  304.  
  305. The DBD driver does not need to worry about this attribute at all.
  306.  
  307. =item $h->{PrintError}
  308.  
  309. The DBD driver does not need to worry about this attribute at all.
  310.  
  311. =item $sth->bind_col()
  312.  
  313. Assuming the driver uses the DBIS->get_fbav() function (see below),
  314. the driver does not need to do anything about this routine.
  315.  
  316. =item $sth->bind_columns()
  317.  
  318. Regardless of whether the driver uses DBIS->get_fbav(), the driver
  319. does not need to do anything about this routine as it simply
  320. iteratively calls $sth->bind_col().
  321.  
  322. =back
  323.  
  324. The DBI code implements a default implementation of the following
  325. functions which do not need to be written by the DBD driver writer
  326. unless the default implementation is incorrect for the Driver.
  327.  
  328. =over 4
  329.  
  330. =item $dbh->quote()
  331.  
  332. This should only be written if the database does not accept the ANSI
  333. SQL standard for quoting strings, with the string enclosed in single
  334. quotes and any embedded single quotes replaced by two consecutive
  335. single quotes.
  336.  
  337. =item $h->errstr()
  338.  
  339. As documented previously, this routine should currently be written for
  340. each sub-package (dr, db, st).
  341. It is not clear why the $h->state and $h->err routines are not treated
  342. symmetrically.
  343.  
  344. =item $dbh->ping()
  345.  
  346. This should only be written if there is a simple, efficient way to determine
  347. whether the connection to the database is still alive.
  348. Many drivers will accept the default, do-nothing implementation.
  349.  
  350. =back
  351.  
  352. =head1 OTHER MISCELLANEOUS INFORMATION
  353.  
  354. Many details still T.B.S.
  355.  
  356. =head2 The imp_xyz_t types
  357.  
  358. T.B.S.
  359.  
  360. =head2 Using DBIc_IMPSET_on
  361.  
  362. The driver code which initializes a handle should use DBIc_IMPSET_on()
  363. as soon as its state is such that the cleanup code must be called.
  364. When this happens is determined by your driver code.
  365.  
  366. Failure to call this can lead to corruption of data structures.
  367. For example, DBD::Informix maintains a linked list of database handles
  368. in the driver, and within each handle, a linked list of statements.
  369. Once a statement is added to the linked list, it is crucial that it is
  370. cleaned up (removed from the list).
  371. When DBIc_IMPSET_on() was being called too late, it was able to cause
  372. all sorts of problems.
  373.  
  374. =head2 Using DBIc_is(), DBIc_on() and DBIc_off()
  375.  
  376. Once upon a long time ago, the only way of handling the attributes
  377. such as DBIcf_IMPSET, DBIcf_WARN, DBIcf_COMPAT etc was through macros
  378. such as:
  379.  
  380.     DBIc_IMPSET     DBIc_IMPSET_on      DBIc_IMPSET_off
  381.     DBIc_WARN       DBIc_WARN_on        DBIc_WARN_off
  382.     DBIc_COMPAT     DBIc_COMPAT_on      DBIc_COMPAT_off
  383.  
  384. Each of these took an imp_xyz pointer as an argument.
  385.  
  386. Since then, new attributes have been added such as ChopBlanks,
  387. RaiseError and PrintError, and these do not have the full set of
  388. macros.
  389. The approved method for handling these is now the triplet of macros:
  390.  
  391.     DBIc_is(imp, flag)
  392.     DBIc_has(imp, flag)    an alias for DBIc_is
  393.     DBIc_on(imp, flag)
  394.     DBIc_off(imp, flag)
  395.  
  396. Consequently, the DBIc_IMPSET family of macros is now deprecated and
  397. new drivers should avoid using them, even though the older drivers
  398. will probably continue to do so for quite a while yet.
  399.  
  400. =head2 Using DBIS->get_fbav()
  401.  
  402. The $sth->bind_col() and $sth->bind_columns() documented in the DBI
  403. specification do not have to be implemented by the driver writer
  404. becuase DBI takes care of the details for you.
  405. However, the key to ensuring that bound columns work is to call the
  406. function DBIS->get_fbav() in the code which fetches a row of data.
  407. This returns an AV, and each element of the AV contains the SV which
  408. should be set to contain the returned data.
  409.  
  410. =head1 ACKNOWLEDGEMENTS
  411.  
  412. Tim Bunce (tim.bunce@ig.co.uk) - for writing DBI and managing the DBI
  413. specification and the DBD::Oracle driver.
  414.  
  415. =head1 AUTHOR
  416.  
  417. Jonathan Leffler (johnl@informix.com)
  418.  
  419. =cut
  420.  
  421.  
  422. package DBI::DBD;
  423. use Exporter ();
  424. use Carp;
  425. use DBI ();
  426.  
  427. @ISA = qw(Exporter);
  428.  
  429. $DBI::DBD::VERSION = $DBI::VERSION;
  430.  
  431. @EXPORT = (dbd_postamble);
  432.  
  433.  
  434. sub dbd_postamble {
  435.     '
  436. DBI_DRIVER_XST=$(INSTALLSITEARCH)/auto/DBI/Driver.xst
  437.  
  438. $(BASEEXT).xs: $(BASEEXT).xsi
  439.  
  440. $(BASEEXT).c: $(BASEEXT).xsi
  441.  
  442. $(BASEEXT).xsi: $(INSTALLSITEARCH)/auto/DBI/Driver.xst
  443.     perl -p -e "s/~DRIVER~/$(BASEEXT)/g" < $(DBI_DRIVER_XST) > $(BASEEXT).xsi
  444. ';
  445. }
  446.  
  447. 1;
  448.  
  449. __END__
  450.