[DB-SIG] DBAPI philosophy (was Re: [DB-SIG] Last round for DB API 1.1)

Greg Stein gstein@lyra.org
Thu, 18 Mar 1999 03:06:03 -0800


Tod Olson wrote:
>...
> In a similar vein, if I were porting, say, a Sybase application to
> MySQL, I would want some indication that a rollback did/could/would
> not happen.  That is, if the DBAPI is to be thought of as an aid to
> portability, I want some clue when a DB module has unexpected
> behavior.  "def rollback(): pass" seems the worst possible case.

Historically, the position has been thus:

It is a very complex problem to attempt to provide a uniform interface
to all possible databases. The DB-SIG and the DBAPI will not attempt to
take on such a task, but will instead create an API specification that
brings *consistency* to database client applications. While the APIs
will be consistent, they will not be guaranteed to be replaceable.


ODBC does a pretty good job of being a uniform interface, and Python has
several bindings to ODBC. However, there are just too many tweaky things
in a database to be able to build truly portable applications
(differences in column types, SQL syntax, available SQL functions, index
behavior, stored procedures, etc). Since you (typically) cannot have an
application that is truly portable, there is not a lot of reason to
guarantee portability at the DBAPI level (when you recode the app, you
may need to recode the API calls).

I believe the DBAPI has largely met its goals. Python programmers
familiar with the DBAPI can rapidly come up to speed against new
databases. I just installed MySQL for the first time a month ago. Took
me all of 10 minutes to write some Python code to call it. Sure, the
parameter binding was different from my experience with Oracle,
Informix, and ODBC modules, but I knew the API already. I was able to
get something done... quickly.

While it is perfectly reasonable for us to change the philosophy behind
the DBAPI and move towards stricter conformance, I do not think that we
should delude ourselves into believing that we can reach that goal. I
think that we can continue using our present philosophy and bring
continued, tremendous benefits to the Python/database community. Over
time, the modules will increase their conformance naturally (e.g. Andy's
new MySQL module is targetted at better conformance than the previous
version).

Back to Tod's pseudo-question: yes, the DBAPI *aids* portability, but
even strict conformance, by the author and client, will not and cannot
guarantee portability. Mostly, I view the DBAPI as aiding
*understanding* and *learnability* of the individual DB modules.

Cheers,
-g

--
Greg Stein, http://www.lyra.org/