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

etc.

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/  :
           ---------------------------------------------------------