[DB-SIG] RE: column type casting

[Dittmar, Daniel]

I'll try to summarize Frederico's proposal as I'm not sure I understood it
correctly:

Conversion python => db is done through the existing constructor (Date,
DateFromTicks etc.)

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
is required?

My annotations:

- 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
following:
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 
> position,
> 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.

Daniel

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.

--
Daniel Dittmar
daniel.dittmar@sap.com
SAP DB, SAP Labs Berlin
http://www.sapdb.org/