[DB-SIG] Experiences with DB-API2.0

[M.-A. Lemburg]

Dustin Sallings wrote:
> Around 22:35 on Jun 20, 2002, M.-A. Lemburg said:
> 
> # > 	I would argue that creating a less ambiguous DB API would prevent
> # > people from having to create such abstractions in the first place.  I
> # > don't really understand the point of a DB API that requires another layer
> # > of abstraction before a programmer can begin to use it.  The abstract
> # > interface maintainer must be aware of every driver that gets written and
> # > write custom code to deal with it, and then where are you?
> #
> # Just curious: have you ever used one of the DB API module yourself ?
> #
> # It is because of the DB API standard we have in Python that there are so
> # mance different database interfaces around.
> 
> 	Yes I have, and I've used a couple of different modules under it.
> I understand that it's progress from having nothing to conform to at all,
> but it's still ambiguous enough that people are writing wrappers to access
> databases generically.

This is on purpose: the DB API spec is intended to map as many
different backend systems as possible. The only way to achieve this
is by allowing a certain amount of freedom on the implementors side.

BTW, if you want to support multiple DB backends, why not
just use mxODBC ? It pretty much interfaces to all major
databases out there and provides a consistent interface to
all of them.

> 	That connection strings were not defined in the spec made it a bit
> difficult for me to get going at first, and I was just playing with a
> couple of drivers.  Trying to create an application that is database
> independent cannot be done using the DB API spec, it's got to be wrapped
> with driver-specific code.

If you want to write database independent applications you
have much more to do than just fiddle with the DB API interface.
The SQL dialects and data types differ *very* much between
databases. I'm even starting to talk about differences in
semantics. The only way to work aroung this is by adding
an abstraction layer which has to be application specific.

> 	I'm not saying the DB API is the wrong direction, it's certainly
> helping, but it needs to get rid of ambiguities and fill in some blanks.
> Any place where there's room for the developer to make decisions that
> affect the way the API is used makes it difficult to write code against
> the API.  Options are only good if they're all required (i.e. the five
> quoting techniques).  That is to say, options for the user of the driver,
> not for the developer of the driver.

I disagree.

The freedom is needed so that you can support
more than just one backend, e.g. a flat file database is likely
to behave differently than a full blown SQL Server.

> 	Now, there may very well be cases where behavior must be optional,
> but there needs to be a good reason.  rollback() on a connection is
> reasonable because some people still use mySQL or similar DBs that don't
> inherently support transactions, but the paramstyle is just obscene.

Certainly not. If you would want to enforce a standard
paramstyle then you'd have to add a parser to the modules
that don't support the "standard" way of writing parameters
defined by some DB API spec.

> 	So, yeah, there are lots of drivers, but you have to learn how to
> use each one at least slightly differently.  As long as this occurs, and
> as long as people have to change code when switching drivers, the API is
> insufficient.

Maybe for you, but not for the majority. The DB API has a very
long success story. This is evidence enough for me that the
approach was the right one.

Again, if you don't like dealing with multiple different
interface use mxODBC and talk to the database via ODBC.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/
Meet us at EuroPython 2002:                 http://www.europython.org/