[DB-SIG] RE: column type casting

[Dittmar, Daniel]

> We need to be able to specify handling for input and output.  

agreed

> I like the idea of a single callable object as the converter 
> so you can easily mix and match for datatypes, but it needs to go both
> ways.  

How can it be a callable object if it goes both ways? Wouldn't it need two
methods for db => python and python => db? I know that Python objects can
have metthods in addition to being callable. But when there are symmetrical
behaviours, it doesn't make sense to make of them the 'call'.

> I'm also partial to my syntax:
> ic.execute("SELECT name, icon FROM icons_table WHERE name 
> LIKE '%.png'", bindings={1, PNGIMAGE})

Not quite sure I like it, I'll see how it looks tomorrow.

> > > A module scope registration will only cause problems (thread-wise
> > > and design-wise too).

I agree with Marc there. If someone wants to mess with module variables,
he/she should do it in his own module.

> >
> > the module scope registration is there to allow you to override the
> > default type casting object: STRING, DATETIME, etc... so we have:

Understood, but not agreed

> > module.register_type(TYPE)  -  convert based on type_code
> > connection.register_type(TYPE)  -  convert based on the type_code
> > cursor.register_type(TYPE, column)  -  convert based on column

Wouldn't it be clearer for the cursor to have separate methods to register
by type and to register by pos?

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
- keep conversion by position only if same command
- make conversion a feature of the exact statement (if a statement cache is
used)

Another idea: conversions that span multiple columns
- DATE + TIME combined into a timestamp
- mime type in STRING + BLOB 

I think that this is too complex to be put into the standard, but how about
a generic cursor wrapper which shows how to write these kinds of filters?

Daniel

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