Re: [SQLObject] Possible bug in EnumCol/EnumValidator

[Oleg B. <ph...@ph...>]

On Thu, Aug 08, 2013 at 09:34:18AM +0200, Gert Burger <ger...@gm...> wrote:
> Oleg Broytman wrote, On 07/08/2013 19:51:
> > On Wed, Aug 07, 2013 at 11:52:15AM +0200, Gert Burger <ger...@gm...> wrote:
> >> Attached is a test case demonstrating the issue. Tested with version
> >> 1.5.0b1 and some previous versions.
> > 
> >    Thanks for the report!
> > 
> >> The EnumValidator checks if the value given is in the list of valid
> >> enumValues but this allows unicode values to match normal string values.
> >>
> >> That allows unicode objects into the SQL generation code which forces
> >> python to create unicode strings instead of normal strings. This means
> >> already encoded values will be decoded again and probably with the wrong
> >> encoding.
> >>
> >> My guess is that the EnumValidator should return only str objects that
> >> are properly encoded.
> > 
> >    At the first glance I'm not sure what should be the correct behaviour
> > for EnumValidator. I'll think about it.
> 
> I'm also unsure hoe EnumValidator should react but I'm pretty sure that
> one needs to either cater for unicode strings in final SQL generation or
> prevent them from reaching that stage and I assume the Validators are
> responsible for encoding.

   Now I think you are right. EnumValidator should convert unicode
values to strings because that how SQLObject currently works -- it uses
str internally and is at most unicode-aware.
   So my plan is to move method getDbEncoding from SOUnicodeCol to SOCol
and use it everywhere validators need the encoding. The change is rather
big so I will only apply it (if the approach will work at all) to
branches 1.5 and the trunk.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.