[PEAK] DB type conversion (for inputs to execute() and
callproc())
Phillip J. Eby
pje at telecommunity.com
Wed Dec 17 09:16:52 EST 2003
At 08:07 PM 12/16/03 -0600, Ian Bicking wrote:
>Oh, just to make it a little more difficult, you can have types that the
>driver knows how to handle, but you won't know how to handle. For
>instance, Access uses something like #MM-DD-YYYY HH:MM:SS# for date
>literals (at least, that's what someone said, I haven't used it). If you
>access Access through the ODBC driver and use parameters, the driver can
>do the appropriate quoting. You don't even have to know that the ODBC
>target is Access -- another database that doesn't have silly date
>representations will work with the same code. However, there is no
>interface to determine the proper string representation of a date. (And
>there's no standard interface for parameters either)
Well, for what I need right now, I don't care about the string
formatting. The DBAPI *does* at least specify parameter types and
insertion styles (paramstyle), so in the long run this'll all get covered
by peak.query, which already has prototype parameter management code. That
is, if you apply a filter or computation that includes a parameter, the
generated SQL will have a placeholder and know what parameter should get
put in at that placeholder. Later, there'll be backend-specific code
generation to handle the proper structure (list, dictionary, tuple,
whatever) that the driver needs for the execute() parameter map.
>Anyway, it's something to keep in mind. SQLObject doesn't handle this,
>because it just seemed too damn annoying, but you might want to.
Yes. Not ever as literals, mind you. I plan to stick with parameter
insertion wherever possible, because strings kind of suck. (The flip side
is that my existing approach to logging SQL content doesn't work very well
with parameters, but oh well.)
More information about the PEAK
mailing list