incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <ole...@gmail.com>
Subject Re: svn commit: r1455576 - in /incubator/bloodhound/branches/bep_0003_multiproduct/bloodhound_multiproduct/multiproduct: api.py hooks.py web_ui.py
Date Wed, 13 Mar 2013 16:41:19 GMT
On 3/13/13, Branko ─îibej <brane@wandisco.com> wrote:
> On 13.03.2013 17:17, Olemis Lang wrote:
>> On 3/13/13, Branko ─îibej <brane@wandisco.com> wrote:
[...]
>>> Not to mention that those 4 variants of i have 6 different Unicode
>>> representations. You do *not* want to deal with Unicode normalization
>>> issues in primary keys.
>>>
>> Like I just said in my previous message ... we already deal with
>> unicode values in primary keys , so that belongs in the past ...
>
> Just make triply sure that Trac core actually does normalize the keys
> before writing them to the database.

Ok . In advance I could say that I've seen before test cases all over
for unicode values and primary keys . Nevertheless , my initial
suggestion will only have an impact on product prefixes , so anything
else in Trac will not be the target , it's BH
;)

> Otherwise I'd consider that a
> serious bug, because it leaves room for having two identical-looking
> primary keys with different bit values.

A few test cases , and invoking `to_unicode` in the right places and
afaict everything will be fine .

> Database collations typically
> are not normalization-agnostic.
>

Yes u'r right ... Trac core takes care of that .

> As far as I can see, Trac core only normalizes the names of attachments.
> That's not enough.
>

there are test cases for others e.g. wiki pages ...

-- 
Regards,

Olemis.

Mime
View raw message