Re: [SQLObject] Unicode support?

[Max I. <ma...@uc...>]

Ian Bicking wrote:

> So maybe Unicode is like dates, messy and ad hoc.  It might be better 
> (or worse) in database servers that accept basic data types; psycopg 
> does all its quoting on the client side.

I see. Amen.

> Also, if you are willing to use a default encoding, you could change 
> converters.StringLikeConverter:
> 
> def UnicodeConverter(value, db):
>     return StringLikeConverter(value.encode('utf-8'), db)
> registerConverter(unicode, UnicodeConverter)

Hmm. Looks like there are a lot of ways to solve this particular 
problem. The only complain is why they are missing in the docs. ;-)

Anyway, thanks a lot.

Surely have to look deeper into the sqlobject to find a sane replacement 
for my current approach.

As for "coverters", will this affect only db->python path or python->db 
path or both? Suspect the answer is UTSL. ;-)

I like very much the idea of being able to register some middle-man code 
between the python objects and db that could solve this conversion 
issues trasparently. I even have another use case at hand - make 
CurrencyCol understand my Money type.

The "validators" approach feels a bit out of place for this, as well as 
idea to subclass a particular *Col class.

> You'll still have to decode strings as they come out of the database, 
> but this will handle any queries you build.  Probably the current 
> behavior of using StringLikeConverter for unicode strings is bad, or at 
> least not helpful, because you'll get all sorts of errors if you have 
> any non-ASCII characters.

OK.