[DB-SIG] RE: column type casting
Thu, 29 Mar 2001 19:20:38 +0200
I'll try to summarize Frederico's proposal as I'm not sure I understood it
Conversion python => db is done through the existing constructor (Date,
To convert db => python, the existing type objects (STRING, BINARY etc.) get
an additional __call__ method. These are the default conversions.
- they can be changed at the module level. In this case, the application has
to implement the type comparison as well
- to convert input at the connection or cursor level, only a callable object
- if we don't allow changing module variables, do the type objects come into
play at all?
- I interpret Brian's ideas about 'consistent mechanism for converting' as
db => python happens in 'driver space', so python => db should happen in
driver space as well (using the constructors happens in 'user space', you
call them explicit in the parameter list to .execute ()).
> > How should a cursor behave when there is a new execute?
> > - forget conversion information (fall back to connection
> default, fall back
> > to default at cursor creation time)
> > - keep conversion by type
> conversion by type should be keeped, maybe even conversion by
> because you want to set the converion stuff once and then to
> many queries
> inside a loop, right?
When you execute the same command again, then you'll want to keep the
positional bindings. When you execute a different command (not that I
would), positional bindings are bound to be wrong.
P.S. Would anyone think it useful to have a Wiki added to this discussion?
Not for the discussion itself. But it would be a fixed place for everyone to
add proposals, example code and everything we agreed upon. This could then
be more easily referenced than some snippets in a mailing list archive.
SAP DB, SAP Labs Berlin