=head1 Parrot DBDI Project: a Database Driver Interface for Parrot =head2 DBDI Goal
The DBDI Project aims to define a "DataBase Driver Interface" (API) and implement a "DataBase Driver Infrastructure" (base classes etc) for Parrot. The goal is to provide a common interface to database drivers at the Parrot level which can then be reused by language-specific database interfaces. So the individual Perl6 DBI, Python DBI, Ruby DBI, PHP DBI etc. can all be built on a common framework and share a common set of database drivers. =head2 DBDI Background The design will be modeled closely on the Perl DBI which is mature, flexible, well proven, and widely used. The database interfaces for several other HLLs were inspired by the Perl DBI to a greater or lesser extent and, ultimately, they're all quite similar. Any functionality needed by a non-Perl DBI will be integrated in. In the text that follows "DBI" refers to the existing Perl DBI unless otherwise specified. The DBI has two distinct parts... The part most people see and use (the DBI class, plus the DBI::dr, DBI::db, and DBI::st handle classes, plus a few utility functions) is actually a small proportion of the code. The bulk of the DBI code is actually in another set of classes. These are the base classes for database drivers: DBD::_::dr, DBD::_::db, and DBD::_::st. These classes provide much of the infrastructure for the drivers, including functionality like column binding, leaving the drivers to focus on the database specific code. This abstrating away of common code makes the job of implementing drivers much simpler. It also means that new functionality, such as bulk operations, can often be added in a way that makes the interface work even for drivers that don't specifically support it. Between these two sets of classes is the method dispatcher, which plays a key role in many of the 'value added' features of the DBI such as automatic error handling, tracing, profiling and subclassing. (I'll talk about the dispatcher later.) Here's a simple diagram showing the various layers including, for the purpose of our discussion, the APIs involved: 0: Application 1: -> (DBI API) 2: -> DBI 3: -> (Driver API) 4: -> Driver 5: -> Driver Base Classes A rather more attractive and detailed version of that can be found in these slides: http://search.cpan.org/src/TIMB/DBI_AdvancedTalk_200307/sld054.htm The interface between the Application and the DBI, labeled "(DBI API)", is the interface Perl users are very familar with. The interface between the "DBI" and the "Driver", labeled "(Driver API)", is very similar to the DBI API but slightly different. It has not had a specific name before because it's only been relevant to a small number of intrepid developers who have implemented drivers. But now I'm going to name it the "DataBase Driver Interface", or DBDI for short. The Perl DBDI is documented, minimally, in the DBI::DBD module: http://search.cpan.org/~timb/DBI/lib/DBI/DBD.pm The "Parrot DBDI" project aims to (re)define that API for Parrot (taking the opportunity to improve it as we go) and implement the base classes behind it. =head2 What about a DBI? The DBDI will be directly usable as a database interface for applications. It will, however, lack a range of important features that are implemented by a "DBI method dispatcher". The full DBI achitecture wraps a driver specific object of a driver specific class, like DBD::Oracle::db, with a non-driver specific object of the DBI::db class. These are known as the inner and outer handles, respectively. This wrapping allows an application or library code to subclass the DBI irrespective of which driver is being used. When a method, any method, is called on the outer handle it executes the DBI dispatch method (all DBI methods are aliases to the dispatch method). The dispatcher switches to the inner handle and calls the corresponding method on that. Apart from that role, the dispatcher also: - Traces method calls with params and exits with results. - Clears error state prior to calling (most) methods. - Checks error on return for printing or throwing exception. - Returns cached attributes. - Optionally checks tainting of params and taints results. - Optionally times method calls per SQL statement for profiling These wouldn't be available when using just the DBDI directly. It is anticipated that individual high level languages will implement their own DBI interfaces layered over the DBDI interface and infrastructure. However, in addition to implementing a functional "DBDI", the DBDI project will implement common components that most DBI's would use. That'll reduce the development required by high level languages. =head2 So why not just call it the "Parrot DBI" project? I wanted to use a different name to avoid any implication that the goal was to create "one true Parrot DBI" in the image of the Perl DBI. That's not the goal. The goal is for many languages to benefit from pooling development effort on a common database infrastructure I<below> the "DBI" level. =head2 What about Drivers? I anticipate that drivers will be implemented using the Parrot Native Call Interface (NCI) to interface with the underlying database API. This has the significant advantage, if it works well, that drivers shouldn't need to be compiled on each platform. =head2 Links to database interfaces for various HLLs Ruby: http://ruby-dbi.sourceforge.net/ Python: http://www.python.org/topics/database/ Perl: http://dbi.perl.org/ PHP: http://freshmeat.net/projects/php-dbi/ (Please let me know about any other similar database interface projects for languages that may target Parrot.) =head2 Developers Harry Jackson <[EMAIL PROTECTED]> has volunteered to lead the development effort with design input from me, Tim Bunce. We're hoping that others interested in database interfaces for Parrot will join us and contribute. I expect a public code repository will be established soon. =head2 Mailing List The [EMAIL PROTECTED] mailing list has been created for this project. Archives can be found at http://www.mail-archive.com/[EMAIL PROTECTED]/ Send email to [EMAIL PROTECTED] to subscribe. =cut
