On Sep 25, 2008, at 2:04 AM, jason kirtland wrote:
> > Shawn Church wrote: >> >> >> On Wed, Sep 24, 2008 at 10:45 PM, jason kirtland <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> wrote: >> >> >> Adding ?charset=utf8&use_unicode=1 to your MySQL connection URL >> is a >> much easier way to get Unicode back from all DB access. >> >> >> Ok, that works. I thought that "create_engine(uri, encoding = >> "latin1", >> convert_unicode = True) would do this. I am guessing from this >> that the >> create_engine arguments are NOT being passed along to the dbapi >> connector? > > No. I believe both of those are specifying the treatment of string > data > going _to_ the DB-API only, not bidirectional behavior. convert_unicode means that all String types will do unicode conversion on the way in and out. The issue here is that the conversion is limited to types which are known to be String. Converting *all* strings to unicode would then lead to havoc as soon as someone adds a Binary column to their schema. Another solution, which we have support for, would be for ResultProxy to attempt to match TypeEngine objects to the DBAPI types in cursor.description. We already do this for Oracle binary types, so perhaps this functionality could be enabled for all types. Its backwards incompatible though so it would need to be a create_engine() option (I'd call it "detect_result_types"). A technical issue with this option is that it creates issues with table reflection which would have to be worked around somehow. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
