OK its False or None by default except on the Unicode type, where its still set to True. Setting it to None on String means the dialect- level flag takes effect, False or True overrides the dialect setting.
I think this will make the next release and adoption of the feature a lot easier. On Nov 27, 2007, at 5:00 PM, Rick Morrison wrote: > > also, what im considering doing, is having assert_unicode only be > > implicitly turned on for the Unicode type specifically. the > engine- > > wide convert_unicode and String convert_unicode would not implicitly > > set the assert_unicode flag. > > That makes more sense to me, and I would prefer it. The contract for > 'covert_unicode' was pretty simple (but maybe wrong) in my mind - > "any str/unicode() put in will be converted according to > Dialect.encoding when going to the database, and decoded from > Dialect.encoding when coming from the database". > > > in this case you get the inconsistent > > round trips. > > That's expected and fine by me. I don't really understand the > insistence on consistent round trips to a database. Databases > convert types, sometimes implicitly. That insistence on consistent > round trips is a fixation on on the "O" portion of ORM, while not > taking into account the "R". > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
