[DB-SIG] Abstraction layer confusion, ULA (was Re: Database Abstraction in Python)

Jonathan Franz jfranz at neurokode.com
Mon Apr 18 15:43:17 CEST 2005

I responded to an email about an abstraction layer, whose author asked 
if such a layer was  a good basis for a dbapi 3 - to whit my response 
was basically 'no, but lets talk about dbapi 3'.  Perhaps I wasn't clear 

As for PDO, I think I might know something about it...

As a maintainer of one such abstraction layer, I have a vested interest 
in making sure dbapi 3 provides the facilities needed for a modern, 
robust user-level api.

Currently, dbapi is lacking many features.

Marc wrote:
"""The next version of the DB API spec will not include any
of these abstraction attempts, but instead focus on
clarifying the DB API 2.0 and possibly moving some of
the currently optional features in the spec to the
mandatory sections."""

Every time changes to the spec are discussed on this list, you make that 
same argument, as if dbapi 3 were something on a shelf waiting for 
release... it is not.  Shouldn't we as a community discuss what is or 
isn't needed in such a spec?

I tend to disagree with the argument on application specific abstraction 
layers; But only because things like PDO (which provides a 
developer-friendly API, No ORM or other abstractions) and ADO are not 
application specific in any way, and yet are tools the average developer 
would (in many cases) choose to utilize rather than write to the 
driver-level interface.

Let us call such a layer a User-Level-Api (ULA), instead of an 
abstraction layer.  Now, what things should such a layer include?   And 
what do we call the driver layer?  And do we still use the dbapi name 
for the bundle of a common ULA and Driver layer?

Perhaps it is time for a PEP.

More information about the DB-SIG mailing list