[DB-SIG] WHat's the status of DB modules and datetime.py supp ort?
Guido van Rossum
guido at python.org
Fri Jan 2 10:53:31 EST 2004
> > exactly. let's start with a first very simple proposal that, imho, will
> > improve the dbapi a lot:
> > objects returned in result sets should be directly useable as bound
> > variables, without needing a call to wrapping functions/constructors.
> > e.g., if datefield is of (any) date type and curs is a cursor:
> > curs.execute("INSERT into test VALUES (%s)", (module.DateFromTicks(x),))
> > curs.execute("SELECT datefiled from test")
> > d = curs.fetchone()
> > curs.execute("INSERT into test VALUES(%s)", (d,))
> This proposal does not address the needs of those that:
> 1) need to take data from one DB-API driver to another driver or backend
> 2) have inherently ambiguous DB->Python type mappings
> 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).
Right, but some of these requirements seem to follow from the fact
that there *are* so many differences between DB-API modules. Doesn't
the addition of a standard, builtin datetime type take away much of
(2) and hence (1), while improving (3)?
> Thus, this proposal should be a use-case for a type mapping extension for
> input and output variables, but is not general enough to be a stand-alone,
> mandated feature.
I imagine it also depends on the smarts of the database. In MySQL, I
seem to recall that string values of a certain format are acceptable
as date input, so if a DB-API MySQL wrapper returned strings (with the
right format) for date values, that would work just fine. But this
may not work for all db vendors.
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the DB-SIG