Assumptions and Principles

Here's another chunk of design notes for consideration...

And and all feedback welcome.

Tim.


=head2 Assumptions

=item 1

The Perl 5 DBI will be available from Perl 6. Either via Ponie or by embedding
libperl5 in some way.

This implies that the new DBI is less urgent than it otherwise would be.

=item 2

The Perl6 DBI API need not be very similar to the Perl5 DBI.

Given assumption 1 above, those who want to keep using DBI v1 can do so.

[For now I'm leaving open the question of whether the new DBI should be named
"DBI2" or keep the name "DBI" and bump the version to 2. There's a whole bunch
of issues there that are best left till Perl6 is more complete and CPAN
infrastructure like PAUSE have some Perl6 support. So I'll leave it for now and
use both "DBI2" and "DBI v2" interchangeably.]

=item 3

The DBI as we know it will be split into two layers. The Perl6 DBI will be a
relatively thin interface layered over a Parrot-level API.  It is hoped that
the Parrot-level API will serve as a common database interface for all
languages targeting Parrot. This is to support Goal 11: "Share drivers across
all languages targeting Parrot".

The Parrot-level API is likely to be modelled on JDBC, the Java database API,
but with appropriate changes to suit Parrot rather than Java.  The Parrot-level
API is a mere implementation detail at this early stage in the process.

This document just outlines the Perl6 DBI API.

=head2 Principles

The DBI is primarily an Call Level Interface (SQL/CLI ISO/IEC 9075-3:1995)
and will remain so. (See http://en.wikipedia.org/wiki/Call_Level_Interface)

Any "Data Access Objects" functionality (like Microsoft ADO or Java JDO) should
be layered over DBI rather than being included within it.
By definition a DAO layer should be technology agnostic to enable change.
The role of the DBI is to provide a stable portable foundation to build on.

Learn from the good and bad parts of mature OO database APIs, such as JDBC.

=cut