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
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.
On Mon, Nov 03, 2008 at 02:07:51PM +0200, Dan Pascu wrote:
> I just committed a fix in handling unicode values.
Oleg Broytmann http://phd.pp.ru/ phd@...
Programmers don't die, they just GOSUB without RETURN.