Uploaded image for project: 'VuFind'
  1. VuFind
  2. VUFIND-1187

Tags are semi-case-insensitive in MySQL-based installations

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.0RC1, 1.0RC2, 1.0, 1.0.1, 1.1, 1.2, 1.3, 1.4, 2.0alpha, 2.0beta, 2.0RC1, 2.0, 2.0.1, 2.1, 2.1.1, 2.2, 2.2.1, 2.3, 2.3.1, 2.4, 2.4.1, 2.5, 2.5.1, 2.5.2, 2.5.3, 2.5.4, 3.0, 3.0.1, 3.0.2
    • Fix Version/s: 3.1
    • Component/s: MyResearch, User Interface
    • Labels:
      None

      Description

      I’ve just discovered a strange behavior in VuFind that I’m pretty sure has existed since day one, but which no one has noticed before. Here’s the sequence to reproduce it:
       
      1.) Go to record A, and tag it “WaCKy”.
      2.) Go to record B, and tag it “wacky” – your tag shows up as “WaCKy.”
       
      Basically, if there are multiple case variations of a tag within VuFind, the first one always wins, and you can never change it.
       
      The reason for this is that MySQL uses a case-insensitive collation by default, so while it can store different cases, it always retrieves in a case-insensitive fashion. This seems to me like a very bad, unintuitive default behavior – but it is what it is.
       
      I think we have a few options:
       
      1.) Ignore it – nobody has complained yet, so maybe it’s not a big deal.
      2.) Force all tags to a particular case – if we want case-insensitive tags, perhaps we should force all strings to lowercase so no one is disconcerted by random, inexplicable case variations.
      3.) Change the MySQL definition to a case-sensitive collation – this would allow “WaCKy” and “wacky” to be treated as two independent tags, which might or might not be desirable. This would require database structure changes, and I’d have to investigate how easy it would be to incorporate into the database upgrade script, and it’s also possible that the change will reveal bugs we haven’t noticed before due to the odd database default.
      4.) Hybrid of 2 & 3 – make the database case sensitive, but include a config setting to allow strings to be forced to lower case. Best of both worlds since it eliminates confusing behavior and makes case sensitivity configurable… but also the most work to implement.
       
      Also note that this ONLY affects MySQL as far as I know… so PostgreSQL users are probably currently experiencing case sensitive behavior. This might be another argument toward option #4, since that would better lend itself to cross-platform consistency.

        Attachments

          Activity

            People

            Assignee:
            demiankatz Demian Katz
            Reporter:
            demiankatz Demian Katz
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: