[Krang-devel] A Case Sensitivity Surprise

[Sam T. <sa...@tr...>]

I made a surprising discovery yesterday.  Krang is, for the most part,
case insensitive when enforcing uniqueness constraints.  Krang won't
let you have one story with the URL "/foo/bar" and another "/foo/BAR".
Nor can you have the contributor "Alfred a. Newman" and "Alfred
A. Newman".

I say this is surprising because it was not done by design and there's
no code in place to enforce it.  Rather, it's something we're getting
from MySQL by accident.  In MySQL, VARCHAR and TEXT contents are
matched case-insenstively by all comparison operators (ex: LIKE and
=).  This can be changed by marking the column BINARY, either in the
table definition or in a cast in an individual expresion.  Marking a
column BINARY also alters its ordering behavior, sorting by byte value
rather than alphabetic ordering.  This puts all upper-case letters
before lower-case letters, for example.

I'm unsure how to proceed.  Although this feature was not implemented
intentionally, it seems to have some benefits.  Users can be confused
by case-sensitive systems.  However, I know of two problems with the
current system:

  - Data imports from case-sensitive systems may lose data entering
    Krang.

  - This "feature" isn't being tested.  I suspect there may be Perl
    code in Krang which is treating character data case-sensitively
    even though the database is not.

So, what do you think?  Should Krang be repaired to be case-sensitive
as it was intended, or should we accept the current state and make
sure it's applied evenly throughout Krang?

-sam