[DB-SIG] Abstraction layer confusion,
ULA (was Re: Database Abstraction in Python)
Jonathan Franz
jfranz at neurokode.com
Mon Apr 18 16:51:20 CEST 2005
> Hmm, I don't see how the DB API limits any module writer
> from adding new features to their implementation.
>
> In fact, many authors have added features to their implementation
> and as a result we have added a special section to the DB API
> to make sure that these features use standardized semantics.
Ack! I guess my definition of a standard is different than yours - I
would see all extensions either made part of the core standard, or
removed from the document entirely. Optional features just confuse the
things.
> It would really help if you could be more specific about those
> lacking features.
>
> The only feature which I'd really like to see in DB API 3.0
> is a standard way to tell the module how to map database types
> to Python types and vice-versa.
That is one of the main ones I want/need for PDO, see my response to
Anthony for others.
> My main concern is that you are trying to reuse the term "DB API"
> in a way which historically doesn't make sense: the DB API
> has always been a very simple API specification focussed on
> very basic database building blocks. The goal was to make
> it easy for module writers to build modules which adhere to the
> spec and to make it easy for users to write code on top of it.
> Think of it as middleware.
Ah, that makes sense, its a naming-and-scope thing. OK.
> If you believe that we need to add features to the DB API spec
> to make the implementation of an abstraction layer easier,
> we can discuss this aspect.
Perfect, that is all I request! Hopefully and/all added features that
would make abstraction easier would also be useful for the application
writer who writes directly to the spec himself, and for those who write
app-specific abstractions.
> If you would like to see e.g. PDO or a similar package
> in Python's standard lib, that's a different discussion.
Whatever the standard ULA is/becomes, that should be suggested for the
stlib, but only after it matures.
More information about the DB-SIG
mailing list