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

[Guido van Rossum]

> > 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()[0]
> > 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
>      database.
>   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/)