Please don't use the term "DB API 3.0" for anything that has to do with database abstraction.
The Python DB API has a different scope. It is a driver interface specification, not a specification for higher level interfaces. The latter can easily be built on top of the DB API and there have been a few successful attempts to do so:
PyDAL started by Randall Smith last year:
http://pydal.sourceforge.net/
ADOdb which was originally written for PHP:
http://adodb.sourceforge.net/
SQLObject which is an ORM layer on top of the DB API:
http://sqlobject.org/
PDO, an OO API similar to ADO built on top of the DB API:
http://pdo.neurokode.com/
(probably others which I don't remember)
If you want to start a new project in that direction, please have a look at the above projects first and see whether one of them fits your needs.
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.
The DB API's aim is to provide a solid and working basis for the many possible abstractions which are commonly used in database programming, from general purpose abstraction layers to per-application implementations.
That said, please note that my recommendation to Tom Haddon is based on my own experience in Python database programming. I've done quite a few of these abstraction interfaces on top of the DB API in many projects and found that you get much better portability if you implement the abstraction based on the application rather than going for an abstraction of the abstration which is bound to have to make compromises one way or another.
Given that the application writer usually knows best what she expects from the database and which database backends she intends to tagret, the per-application abstraction interface has usually turned out to be the best choice in terms of flexibility, robustness and performance. It also makes it easier to adapt the application to various backends - hiding the SQL, matching the database data types to application data types and tweaking varying database semantics to fit the application's needs.
Again, that's my experience. YMMV.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Apr 18 2005) >>> 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 ! :::: _______________________________________________ DB-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/db-sig
