Roundtrip SQL data especially datetime
dyork
reverseyorkage at david.com
Sun Dec 17 08:26:40 EST 2006
"Carsten Haese" <carsten at uniqsys.com> wrote in message
news:mailman.1683.1166244629.32031.python-list at python.org...
> Python is a typed language, too, and "this thing" works just fine,
> provided that you are using a reasonable DB-API implementation, and
> provided that you're actually binding objects as parameters instead of
> just sticking literal strings into your query.
I'm currently using MySQLdb, but I'm looking for solutions that work
universally.
Binding objects is no different from literal strings. Since there is no
portable underlying type for an SQL date, the interface will AFAIK always
finish up using strings. At some point the SQL parser has to convert a
literal string, either embedded in the query or bound as a parameter, into
the equivalent date. I really hope the dbapi will know how to choose the
right string format so I don't have to, but so far that's not at all
certain.
> When reading stuff from the database, keep the results in whatever form
> they come. Convert to strings for display purposes if you must, but
> don't overwrite the object you got from the database if you intend to
> save it back into the database.
That's not feasible. For Web stuff, the object from the database got thrown
away after the page was rendered. We're dealing with a whole new request,
with little or no previous state, and all the dates coming in with the
request are strings, using formatting that depends on what the user wanted
to see. I need to package that into a form ready for either an INSERT or
UPDATE query. The user might have typed in dd-mmm-yy order, but the database
interface might use mm/dd/yyyy. It needs two conversion layers, and I would
rather use someone else's than write my own. Lazy, I guess.
DY
More information about the Python-list
mailing list