[DB-SIG] DB API 1.1 Spec

Greg Stein gstein@lyra.org
Fri, 12 Mar 1999 03:07:09 -0800

M.-A. Lemburg wrote:
> Just wanted to remind you that the deadline for the last call is
> this Friday.

Reminder: Friday is last call for this round. The spec then receives all
updates to produce a "final draft" for consensus sign-off on March 26.
The new spec is posted on March 29.

> The latest version of the proposal can be found at:
>         http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html
> Feel free to comment on it. Greg Stein has created an annotated
> version which is available at:
>         http://www.lyra.org/greg/anno-DatabaseAPI-1.1.html

I have updated the annotated version to match 1.1a7 (Marc's most recent

> Some things still open for discussion (some of which may go into
> 1.2):
>  punting dbi (by folding its features into the database modules
>   themselves)

Let's do this. This would clean things up quite a bit. I do not believe
the dbi thing provided all the benefits that it could have. And compared
to the cost, we should nuke it.

>  developing a few more common sets of types, e.g. for passing
>   raw data, monetary data, etc. which may be used by the interface
>   modules to bind the correct type

I'm somewhat ambivalent here.

What might be interesting is to define how an object must respond, and
leave it to implementors to use a class instance or builtin type. For

class MyDBValue:
v = MyDBValue()
v.dbtype = 'RAW'
v.value = 'abcdef'

The DBAPI would specify that "object.dbtype == 'RAW'" means that the
object represents a RAW value, which is a read-buffer in the .value

== 'CURRENCY' means a monetary unit where .value is an integer or float
or something.


>  designing a common package layout for the database packages

If we nuke dbi, then a package is not required. However, I believe it
would be fair to spec a "typical" pair of .py and .so modules (e.g.
somedb.py and _somedb.so).


Greg Stein, http://www.lyra.org/