DBI - The Perl5 Database Interface by Tim Bunce.

Copyright (c) 1995,1996 Tim Bunce

You may distribute under the terms of either the GNU General Public
License or the Artistic License, as specified in the Perl README file.


WARNING: THIS IS ALPHA SOFTWARE. IT IS POSSIBLY UNRELIABLE!

WARNING: THIS SOFTWARE IS ABOUT TO CHANGE DRAMATICALLY!
         See the 'New Directions' message at the end of this file.


This DBI interface is not yet fully specified. The current development
work is focused on writing drivers, such as DBD::Oracle, which also
implement emulations of old perl4 database interfaces, e.g., oraperl.
This strategy enables the DBI and drivers to serve a useful purpose
whilst allowing the real interface to evolve with experience behind the
emulation interface.


For more information and to keep informed about progress you can join
the a mailing list via http://www.fugue.com/dbi (if you are unable to use
the web you can subscribe by sending a message to dbi-request@fugue.com,
it may take a few days to be processed).

Much useful information and online archives of the mailing lists can be
found at http://www.hermetica.com/technologia/DBI

See also ftp.demon.co.uk:/pub/perl/db and "CPAN" ftp sites.


BEFORE BUILDING, TESTING AND INSTALLING this you will need to:

    Build, test and install Perl 5 (at least version 5.002beta2).
    It is very important to test it and install it!

BUILDING

    perl Makefile.PL
    make
    make test
    make test TEST_VERBOSE=1   (if any of the t/* tests fail)

    make install (if the tests look okay)

Do NOT hand edit the generated Makefile unless you are completely sure
you understand the implications! Always try to make changes via the
Makefile.PL command line and/or editing the Makefile.PL.
 
You should never need to make any changes. If you do *please* let me
know so that I can try to make it automatic in a later release.
 

IF YOU HAVE PROBLEMS:

Please post details to dbi-users@fugue.com and CC them to me at
Tim.Bunce@ig.co.uk.  Please include:

1. A complete log of a complete build, e.g.:

    perl Makefile.PL           (do a make realclean first)
    make
    make test
    make test TEST_VERBOSE=1   (if any tests fail)

2. The output of perl -V

3. If you get a core dump, try to include a stack trace from it.
   If the stack trace mentions XS_DynaLoader_dl_load_file then rerun
   make test after setting the environment variable PERL_DL_DEBUG to 2.

4. Please DON'T post problems to comp.lang.perl.misc or perl5-porters.

5. If you are not currently subscribed to the mailing list please
   join (see note above).


Regards,
Tim Bunce.

=======================================================================

Drivers planned or being developed:

Oracle		- Tim Bunce <Tim.Bunce@ig.co.uk>
Ingres		- Tim Bunce <Tim.Bunce@ig.co.uk>
mSQL		- Alligator Descartes <descarte@mcqueen.com>
Informix	- Alligator Descartes <descarte@mcqueen.com> 
Interbase	- Bill Karwin <bkarwin@interbase.borland.com>
DB2  		- Mike <mhm@austin.ibm.com>

Please communicate about these via the dbi-users mailing list.
Thanks.

Tim.

=======================================================================

From: Tim.Bunce@ig.co.uk
Date: Tue Dec 12 01:29:26 1995
To: dbi-announce@fugue.com, dbi-users@fugue.com
Subject: New directions for DBI - Important

I've been putting off writing this message because I've little time
to deal with the fallout it's bound to create... but I don't want
to leave it any longer. It's too important.

As you may remember I went away for a couple of weeks vacation recently
saying that I'd be thinking about ODBC and how it fitted in with the DBI.

To cut a long story short I've decided that we should throw away a
significant chunk of the work that we've done and reengineer an
implementation based very strongly around the SQL CLI / ODBC API.

My reasoning goes something like this:

 - The SQL CLI has recently been adopted as an international standard.

 - ODBC is based on the SQL CLI standard and Microsoft has commited to
   make ODBC v3 a proper superset of the standard.

 - Database vendors (include Infomix, IBM, Watcom, etc.) are 
   adopting ODBC as the native CLI for their database engine(s).

 - ODBC has *huge* market share on PC's and a very rapidly growing
   presence on UNIX (Solaris 2.5 comes with an ODBC driver manager,
   other vendors are likely to do the same). A large number of commercial
   drivers already exist. Non-commercial drivers are being developed.

 - The DBI currently lacks much of the breadth required for a full
   featured API. Defining the API would duplicate much of the work
   standardised by the SQL CLI / ODBC API.

 - The DBI needs to support ODBC well for it to be widely accepted
   as the standard perl database interface. Specifically it would
   need to expose the majority of the API and associated concepts.
   A DBD::ODBC offering only the current DBI API is not sufficient.

 - A free driver manager exists (Ke Jin's iODBC) and free drivers can
   be implemented with approximately the same skill level as DBD drivers.

And finally some carrots, in case you still need them:

 - I believe that we will be able to implement ODBC drivers for
   loading into perl which are implemented as Perl scripts.

 - I also believe that it should be possible to implement ODBC
   drivers in Perl which can be loaded into non-perl applications!

 - The DBI will no longer be incomplete and undocumented!


Okay, so what's the plan? What will the new 'thing' look like?
Will my current DBI scripts still run? Questions, questions.
I'm sure you'll have many more than this.


The initial step is to carefully define a fairly formal 'perl language
binding' for the SQL CLI / ODBC API. Basically this involves some easy
decisions like "string input parameters do not need a separate length
parameter to we'll delete it for all functions" and some hard and/or
subtle ones, like how best to model handles or deal with descriptors.
(Handles will almost certainly be objects, unlike existing ODBC modules.)

There will be some tough decisions to make but I'm very keen to avoid
limiting the access to the underlying API functionality. Basically
anything that you can do in C (or COBOL!) you should be able to do in Perl.

Once that's agreed I'll implement it. It should be very straight forward.
(Much less work than I'm throwing away :-) I'll implement it over at
least one commercial driver manager and also over the free iODBC manager.
I may borrow some code from Andreas Kaiser's DB2CLI module if he's happy
for me to do that and I decide I want to do some things the same way.

Over this complete but low level API we'll layer some high level methods
that will give us our familiar DBI interface back (as far as possible).

At this point we'll have complete API useable by anyone who can
acquire an ODBC diver. Note that some (many?) database vendors are
giving away drivers.

The next stage is to develop some drivers for databases and/or platforms
where free drivers are not available. I envisage a scheme whereby I
define and implement as much support structure as possible to make it
easier for others to follow in my footsteps. Similar to DBD::Oracle.

The final component is the infrastructure for implementing drivers in perl.


It would be of *great* help to have the *active* contribution of people
who have used ODBC in real world applications. I hope Andreas Kaiser
and Ke Jin will join the mailing list if the're not already on it.
Meanwhile I suggest that everyone else start learning the SQL CLI /
ODBC API!  Many books are available from many bookstores.

I'll stop here and leave you to absorb the meaning of all this.

Feel free to comment on the above but please avoid getting into
technical issues just yet. The time for that will come.

And please note that I'm going to be very short of time till mid-Jan.
I have real-work-deliverables to deliver :-(


Tim.

(Sympathy for throwing away much of the DBI and DBD::Oracle would
 be appreciated. Merry Christmas :-)

