Re: [SQLObject] Possible bug in EnumCol/EnumValidator
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
|
From: Oleg B. <ph...@ph...> - 2013-08-08 09:48:03
|
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.
|