[DB-SIG] DB-API 1.1

[Harri PASANEN]

M.-A. Lemburg wrote:
> 
> Jim Fulton wrote:
> >
> > M.-A. Lemburg wrote:
> > >
> > > M.-A. Lemburg wrote:
> > > description
> > >
> > >      This read-only attribute is a tuple of 7-tuples. Each 7-tuple
> > >      contains information describing each result column: (name,
> > >      type_code, display_size, internal_size, precision, scale,
> > >      null_ok). This attribute will be None for operations that do not
> > >      return rows or if the cursor has not had an operation invoked via
> > >      the execute() method yet.
> > >
> > >      The type_code is equal to one of the dbi type objects specified
> > >      in the section below.
> > >
> > >      Note: this is a bit in flux. Generally, the first two items of
> > >      the 7-tuple will always be present; the others may be database
> > >      specific.
> >
> > This is bad.  I suppose we are stuck with this for backwards
> > compatibility.
> 
> I guess so, too :(
> 

Just for the record, I don't care if description is changed to
something more descriptive in not backwards compatible fashion.

I would however like to get the exact metadata out of the DB,
ctsybasemodule actually lets me do it by abusing description,
as the old spec is so loose here.

I would like to see a mapping from Python DB-API types to database
native types, and the guarantee that dbi types accross databases
are equal, so that no data is lost if Python is used to
bridge two databases.  Also conversion from database type
to Python and vise-versa should never be lossy.

I guess the problematic types are dates, and different decimal
(money) types.

I'm not sure if dbi-types should be a union of all
supported database types, with clear separation of the
set of types that represent the intersection of different db
type sets.  Truly portable programs would the just rely
on this intersection, but db-specific munging would also
be possible.  Hmm... someone can maybe find a better wording
for this.

> >
> > If I were designing this interface I would have description
> > be a collection object that acted as both a sequence of
> > column definitions and a mapping from column name to column
> > definitions.  I would have the column definitions be objects
> > that have methods for standard attributes like name, and type
> > (and maybe nullability, scale and precision)
> > as well as optional attributes for things like display size and
> > internal size.
> 
> Especially those last two don't make too much sense now-a-days
> (probably did back when all output had to formatted for 80-
> column display/printers).
> 

Actually the internal size is useful when estimating how much
storage space is needed.


Just another 2 centimes,

Harri