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

[Gerhard Häring]

* Dustin Sallings <dustin+pydbsig@spy.net> [2002-06-21 13:36 -0700]:
> [to MAL]
> You're saying that DB API can't be any more standardized because
> it'd prevent multiple backends from being used, and if I want something
> more standardized, I'd have to go with another database API that is
> already standardized and provides access to multiple backends.  The
> existence of even one invalidates the first statement, but java, perl,
> ruby, etc... each has a database API providing common access across
> multiple databases.
> 
> 	Again, I'm not saying it's worthless, but it does need to be
> fixed, and it's *certaily* possible to have an abstracted database API
> that will work the same way across multiple databases without having to
> modify application code.
> 
> 	Fixing it will likely require some tough decisions to be made and
> will mostly likely place a greater burden on driver developers, but, IMO,
> that's OK.  I believe a few people have mentioned that creating a base
> framework from which all database implementations should extend, and I
> think that's an excellent idea.

I also think that the base framework would be an very good idea. +1 on
creating one. Who's joining?

> [...] Because the lack of consistency in the API would mean that I would
> first have to know about all DB API implementations, have the databases to
> which they connect, and write special code for each individual API
> implementation, even if the same query were being sent through.

It would also be useful to make sure that the same exceptions are thrown
in the various backends. The correct exception to throw is sometimes
difficult to find out from the DB-API specs.

As a module developer _and_ user, I'd like to get away with the various
paramstyles and have only one paramstyle standardized. I personally like
pyformat best. Alternatively, some wrapper in the base framework to
convert from the standardized paramstyle to the one the module is using
internally.

Also, standardizing connectin parameters looks like a good idea, and I
also like the MySQLdb extension def
cursor(cursorclass=self.defdefaultcursor) in the Connection class. I've
borrowed this for PySQLite and I believe we'll also add it to PyPgSQL.

In short: I don't agree with the argument that the implementation
freedom for paramstyles et al. buys the developers much.

As PyPgSQL 3.0 will be the first release to require Python 2.2 that
looks like a good time to add other possibly incompatible changes, like
a revised DB-API.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id AD24C930
public key fingerprint: 3FCC 8700 3012 0A9E B0C9  3667 814B 9CAA AD24 C930
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))