[DB-SIG] DB API 1.1 Spec

M.-A. Lemburg mal@lemburg.com
Fri, 12 Mar 1999 13:43:40 +0100

Greg Stein wrote:
> > 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
> version).
> > 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.

Ok, I'll fold the dbi symbols into the interface spec.

> >  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
> example:
> class MyDBValue:
>   pass
> 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
> attribute.
> == 'CURRENCY' means a monetary unit where .value is an integer or float
> or something.
> etc.

It would be a lot easier for the module implementor to just
do a type check, but I agree this would also make the setup
a little less flexible.

I'd propose to leave the decision to the implementor and
merely fix the names of the constructors to be used
so that a programmer can rely on those being available
through the interface module, e.g.

Date(year,month,day) for date values
Time(hour,minute,second) for time values
Timestamp(year,month,day,hour,minute,second) for time stamps

Raw(string_data) for raw values

Currency(value,currency_name_as_string='') for monetary values


These constructors will then produce objects that the
module can handle as input values. Output values *should* be of
the same type, they need not necessarily be though (may be a little
to open...).

> >  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).

True. Though I can picture an OO abstraction layer on top of
the API, which would then be distributed as package... that's
for a future revision...

Marc-Andre Lemburg                               Y2000: 294 days left
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :