I just committed a fix in handling unicode values. The StringCol had an asymmetric behavior. When it read values from the database, it would use the database encoding to get a string if the db drivers returned an unicode value. However when an unicode value was given from python it would use a hardcoded ascii codec to get the value to write in the database. This asymmetry was weird and I have no idea why it was like this in the first place. It makes sense to use the database encoding for a value that will be written to the database in a column with that encoding. As a side note, the UnicodeCol uses the defined dbEncoding for both in and out of database operations.
I believe that this was the reason why so many people reported problems when using StringCol and they had unicode values on input with non-ascii content. The suggestion was to use UnicodeCol instead, but that is no longer necessary with this fix applied, as a StringCol will work just fine with unicode input as long as it can be encoded in the database encoding. As it is now, the only difference between StringCol and UnicodeCol is that the later will allow one to define the db encoding per column, while the former will use a database/table wide encoding and one will return strings while the other unicode objects. But overall there should be more symmetry and consistency in how they are handled. -- Dan ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
