[DB-SIG] WHat's the status of DB modules and datetime.py supp ort?

[M.-A. Lemburg]

Federico Di Gregorio wrote:
> Il mer, 2003-12-31 alle 18:14, Vernon Cole ha scritto:
> [snip]
> 
>>    At that time, Jon Franz remarked: " Unfortunately, I think you've fallen
>>victim to some of the hubris present in the SIG. Many of the people here
>>seem perfectly fine with the status quo.  Perhaps they worked on DB-API
>>specifications, and thus feel protective of it?
> 
> it can be. i *only* worked at the last revision of the dbapi when some
> parts where clarified and there were some small additions. and i don't
> feel protective. :) maybe people that have contributed much more than me
> feel that forcing tens of developers to upgrade adapters to a new api is
> a bad thing.

Since I've always tried to keep up the spirit of the DB API
spec ever since I was editor of the 2.0 version, you probably
feel that I'm protective of it.

It is true that I've invested
a considerable amount of time into discussing the various
issues raised with 1.0 on this list and after 2.0 was released
amended it various times (without changing the version number)
in fully backwards compatible ways (e.g. by adding standardized
extensions that we discussed on this list some time ago).

However, that is *not* the reason of why I think making the
DB API more restrictive is a bad thing. The spirit of the DB
API spec has always been to give developers a guideline in
creating new database modules while not making the implementation
too burdensome. As a result we have quite a few database modules
out there which implement the spec, including some of the extensions.
They also often come with a multitude of new developments
that are permitted by the spec (e.g. customized row objects
that behave like a sequence).

By making the spec more restrictive we would not only make
life of the developers harder, but also break backwards
compatibility of most database modules that work perfectly
OK today.

My aim has always been to see what database developers
come up with and then standardize those new ideas in a
way that makes life easier for the user. The database
extensions are a good example of this practice and I
have strong belief that this method of evolving the
standard has proven to be much more of a success than
trying to break compatibility every year or so by trying
to stay bleeding edge all the time.

Many of the things people have asked about in the past
are really not intended to be implemented at the level
the DB API is working at. Object relational wrappers,
ADO style access, etc. can easily be programmed on top
of the DB API and indeed have been implemented quite
successfully for a number of database modules out there.

If someone feels we need a standard for these wrappers,
I'd suggest to first look at the question whether there
will ever be more than just one or two such wrappers
written. I've been in the database business for quite
some time now and to be honest, every single application
has had slightly different requirements for the database
abstraction layer - no single API would have captured
all cases. Of course, that's just my personal opinion.
If people like the existing OR-wrappers, they should
simply use them.

> my oppinion is that the part of the dbapi related to typecasts is
> flacky. 

Probably because it only defines them for the input side
and not the output side :-)

It is certainly a weak point in the spec and we should
do something about it for the next revision.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 02 2004)
 >>> Python/Zope Consulting and Support ...        http://www.egenix.com/
 >>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
 >>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::