Now that we have shaped Bloodhound MP into a more robust solution , I bring this thread to front once again .
On 3/13/13, Branko Čibej <[email protected]> wrote: > On 13.03.2013 17:17, Olemis Lang wrote: >> On 3/13/13, Branko Čibej <[email protected]> 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. >>> Definitely sure . >> Like I just said in my previous message ... we already deal with >> unicode values in primary keys , so that belongs in the past ... > Even if unit tests revealed that product models do support unicode prefix, functional test cases highlighted that hooks did not , therefore they are not actually working in practice . > Just make triply sure that Trac core actually does normalize the keys > before writing them to the database. The patches for #463 have been written with these goals in mind : - Equivalence of compatible unicode strings (e.g. NFD) with NFC form - Upgrade hooks to deal with unicode prefix > Otherwise I'd consider that a > serious bug, because it leaves room for having two identical-looking > primary keys with different bit values. - ... ensure that canonically equivalent unicode strings are bound to the NFC form , therefore preventing duplicated prefix issue * because, yes , that will definitely happen * but note that afaict it's still possible to have identical-looking «compatible» product PKs with different bit values see https://issues.apache.org/bloodhound/ticket/463#comment:5 About this subject I have a few observations and questions and I'd like to hear further opinions: - IMO non-NFC (e.g. NFD) PK URLs have to be redirected (HTTP 301) to match the location for the corresponding NFC string. * e.g. http://127.0.0.1:8714/products/Ame%CC%81lie would be redirected to http://127.0.0.1:8714/products/Am%C3%A9lie * This is a bit difficult to achieve with current hooks, therefore it's still WiP ... * Is it ok to keep the non-NFC URL - An intermediate step of the NFC normalization process seems to be the NFD form . * Considering performance, isn't it better to use the later (i.e. NFD) as a reference? - Is it more accurate to match «compatible» PKs (i.e. NFKC, NFKD) ? [...] > > As far as I can see, Trac core only normalizes the names of attachments. > That's not enough. > You are definitely right . So far I have detected that this might be an issue with milestone names and wiki pages . Does any other model have a PK that might be affected by this kind of issues ? [...] -- Regards, Olemis - @olemislc Apache™ Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article:
