[DB-SIG] WHat's the status of DB modules and datetime.py supp ort?

Kevin Jacobs jacobs at penguin.theopalgroup.com
Fri Jan 2 10:00:28 EST 2004

On Fri, 2 Jan 2004, Federico Di Gregorio wrote:
> Il ven, 2004-01-02 alle 15:29, Kevin Jacobs ha scritto:
> [snip]
> >   1) need to take data from one DB-API driver to another driver or backend
> >      database.
> as already said by a few people on this list the DBAPI is not a
> cross-database-backend tool. it is there to provide a common API, not to
> guarantee database independence.

I agree, though the problems related to multiple backends still exist when
dealing with a single DB-API backend.  It has everything to do with adding
features with the wrong granularity -- i.e., features that require the use
of blessed types in order to be used as bound variables.

At their essence, the last I saw of them, all of the implementations of this
proposal specify the backend type and thus the literal encoding of Python
objects.  The problem is that this information is part of the object type
(e.g., a __sqlstr__ or __sqlrepr__ magic method).

This is easy when all data come from the DB-API driver and are passed back
to that driver, though things become much more invasive when data come from
user interfaces, or other sources that do not have the magic type

> >   2) have inherently ambiguous DB->Python type mappings
> the whole DBAPI is _based_ on ambiguous mappings. i agree with marc on
> that: it does not make sense to force a unique set of type mapping
> because it would be too a burden on the module developers.
> what we need is, imho, a way to tell that a STRING from a database can
> be safetly mapped to a STRING on another backend. and so on. mm.. this
> seems "protocols"[1] stuff to me.

You miss the point.  Your literal round-tripping proposal does not address
the needs of those with data elements that may have _multiple_ literal
forms.  i.e., the type is not enough to specify the literal encoding when
used as a bound variable.

> >   3) like the fact that DB-API adapters return builtin Python types in most 
> >      cases (if only for efficiency reasons since they have their own type
> >      or OR mapping systems built upon DB-API).
> i don't understand what you mean here (not a native english speaker,
> sorry, i know this is my fault.)

Put simply: I want the simplest, most primitive, most light-weight types
returned in rows.  This way I can apply my own type mapping layer without
sacrificing efficiency for any superfluous and/or flawed functionality.


Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (440) 871-6725 x 19         E-mail: jacobs at theopalgroup.com
Fax:   (440) 871-6722              WWW:    http://www.theopalgroup.com/

More information about the DB-SIG mailing list