=head2 DBDI Goal
The DBDI Project aims to define a "DataBase Driver Interface" (API)
and implement a "DataBase Driver Infrastructure" (base classes etc)
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:
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:
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
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
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
(Please let me know about any other similar database interface
projects for languages that may target Parrot.)
Harry Jackson <ha...@uklug.co.uk> 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
Send email to dbdi-dev-...@perl.org to subscribe.