[PEAK] DB type conversion (for inputs to execute() and callproc())

[Phillip J. Eby]

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.)