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