right unless they do the "override column type" thing.  which is inconvenient if they want Decimal all over the place.

im thinking that with this, along with the various unicode requests we've had, that some real engine/dialect level "this is the official map of types I'd like you to use" type of thing needs to be created, which is more generic than having flags like "convert_unicode" and such.  but then it would also have to be easy.  not sure.  heres some ideas:

explicit keywords:

x = create_engine(url, string_type=Unicode, numeric_type=Decimal)

translate python types to SQL types (i think this is problematic):

x = create_engine(url, types = {str : Unicode, float : Decimal})

translate generic SA types to more specific SA types:
x = create_engine(url, types = {String:Unicode, Numeric:Decimal})

just list out the more specific types, which "know" how to replace their more generic types, i sort of like this one but not sure if it works:

x = create_engine(url, use_types = [Unicode, Decimal])




On Jun 3, 2006, at 4:55 PM, Rick Morrison wrote:

Or maybe a different column type so that user can control what comes back. Course that wouldn't work with table reflection....

Rick


On 6/3/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
for this one,  i would think "float" would be the default.  then what do we do for people who specifically want a Decimal ?  sounds like another flag-like situation like "convert_unicode".

On Jun 3, 2006, at 2:16 PM, Rick Morrison wrote:


On 6/3/06, Michael Bayer <[EMAIL PROTECTED]> wrote:

The Numeric types in SQLAlchemy dont modify the incoming or outgoing
return type of bind parameters at all.  

Maybe they should. Letting the DBAPI driver "do what it wants" for type conversion breaks the database independence that SA purports to provide, no?

Rick





_______________________________________________
Sqlalchemy-users mailing list
Sqlalchemy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users

Reply via email to