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

Federico Di Gregorio fog at initd.org
Mon Jan 5 05:50:09 EST 2004

Il ven, 2004-01-02 alle 22:44, Kevin Jacobs ha scritto:
> I don't disagree that you can write code to round-trip any datum from fetch
> to bound argument.  However, the real trick is doing that in such a way that
> the datum is useful in between -- i.e., if all we cared about was naive
> round-trip-ability, then we'd pass around pre-escaped literal strings


> everywhere.  However, I can SELECT an integer, add 1.5 to it, and be very
> annoyed when the literal representation is or is not truncated/rounded back
> to an integer without regard for the destination field type.  This is where

unfortunately the right solution, even for a case simple as yours
involves some kind of knowledge about the column types. that's why we
have the type constructors like DateFromTicks in the modules. the only
reason why we don't have IntFromFloat is that this functionality is
built-in in python, e.g., "int(...)". here is a sketch of a propostal:

1/ let's extend the dbapi by adding some usefull things (as the
round-trip, imho, but there are other extensions that can be usefull for
higher-level module implementors, like some more type singletons) that
does not depend on knowledge of column types.

2/ let's extend the dbapi with a standard way to extract
type-information (and other kind of meta-information from the database).
i *know* people think the dbapi is not the place for this; we can start
a new PEP or anything else but i think we need a standard way to access
meta-information right now.

3/ with the type information would be quite easy to write a
(protocols-based?) utility module that automatically convert the types
so that they can be safetly used cross-db. quoting is to be left to the
DBAPI proper, we only need to convert to a type that the specific DBAPI
implementation can understand. something like:

# pcurs is a psycopg cursor
# mcurs is a mysql cursor

pcurs.execute("SELECT datefield FROM test")
pdate = psycopg_curs.fetchone()[0]
mdate = adapt(pdate, mysqlinterfaces.IDATE)
mcurs.execute("INSERT INTO test (datefield) VALUES (%s)", (mdate,))

don't look at the formalism (adapt), look at the underlying idea. if we
know enough about types, we can provide conversion functions from one
module to the others quite easily. maybe we don't even need point (2) to
write (3). 

>   Do you want to map SQL types to and from native classes, or do you need
>   something more specialized?
> I am in favor of letting the DB-API user decide which perspective benefits
> their application best, rather than mandating anything simplistic or
> invasive that any sophisticated user will want to bypass anyway.

agreed. that's why i built into psycopg a user-customizable type-system
from the start :) [and sincerely, i would like to see the
type-registration system standarized in DBAPI-3.0. i know other modules
provide the same functionality...]


Federico Di Gregorio                         http://people.initd.org/fog
Debian GNU/Linux Developer                                fog at debian.org
INIT.D Developer                                           fog at initd.org
  Those who do not study Lisp are doomed to reimplement it. Poorly.
                                     -- from Karl M. Hegbloom .signature
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Url : http://mail.python.org/pipermail/db-sig/attachments/20040105/25d992e8/attachment.bin

More information about the DB-SIG mailing list