[DB-SIG] Suggestions for DB-API improvements

[M.-A. Lemburg]

Kevin Jacobs wrote:
> On Sun, 7 Jul 2002, Itamar Shtull-Trauring wrote:
> 
>>Kevin Jacobs wrote:
>>
>>>The question is how to get driver authors to support all these new
>>>requirements.  Maybe we need multiple levels of compliance within the
>>>DB-API?  What exists now could be "entry-level" compliance, so that we can
>>>define "intermediate-level" to include some of the easier features, and have

No way :-)

ODBC did this and the result is a complete mess. We don't want
to go down that road.

If you need more capabilities or features, these should be crafted
on top of what we have and use a different name, e.g. Abstract DB API.

>>Maybe it's time to make a DB-API *library*, so authors of support for specific
>>database adapters don't need to do all this work from scratch.
> 
> 
> I would like to see this happen, but I am not sure how realistic it is.  For
> example, how would we integrate support for products like mxODBC, which is
> commercially licensed?

Why should that be a problem ?

I you can come up with a DB API support library on top of the
existing DB API standard, then plugging in the various underlying
DB API compatible modules would not cause you any license issue.

> Some advantages of a library are:
> 
>   1) Unified exception hierarchy
>   2) Ability to build higher-level abstractions, like business-objects
>      (think ADO), driver-agnostic connection pooling, managed connection
>      configuration, etc.
>   3) More shared implementation
>   4) More active maintenance (more eyes == better code)

Looks like you're looking for a standard abstraction layer
on top of the DB API specs.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/