[dev] Case insensitive unique key, was: [horde] Error when updating DB scheme for kronolith
Michael Rubinsky
mrubinsk at horde.org
Mon Apr 11 17:55:21 UTC 2011
Quoting Jan Schneider <jan at horde.org>:
> Zitat von Michael Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> Zitat von MarkatOSI <buy at mark.net>:
>>>
>>>> Problem solved. I found a similar situation described in another posting
>>>>
>>>> "I'm having the same issue :
>>>> SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry
>>>> 'Nmaurice' for key 'rampage_users_user_name'
>>>>
>>>> But over here nmaurice is a user and in our case, I'm guessing that
>>>> this user usually logs in as 'nmaurice', and logged in at least once
>>>> as 'Nmaurice'.
>>>>
>>>> After running the following query, the migrate script was happy.
>>>> mysql> update kronolith_events set
>>>> event_creator_id=lower(event_creator_id);
>>>
>>> The core problem is that we have a unique key on
>>> rampage_users.user_name. Whether this key is case sensitive or not
>>> depends on the table's/database's collation in MySQL. By default
>>> any indexes are case insensitive. This breaks because Horde itself
>>> is case sensitive.
>>> The options that I see are:
>>> - normalize usernames in Content (not good because it would make
>>> Horde case insenstive in a single place)
>>> - enforce collation during table creation (not portable, not sure
>>> if possible, you can't just pick cs vs ci but also have to pick a
>>> locale for the collation)
>>> - make this a regular key an ensure uniqueness in userland code
>>> (not as elegant)
>>> - ???
>>
>> This is only an issue when the authentication backend is case
>> insensitive, right? Wouldn't ensuring the username is case sensitive,
>
> No, it doesn't have anything to do with the authencation backend.
> Whether Joe and joe are different users in the backend or not
> doesn't matter, they are always different users in Horde.
>
>> when using an auth backend that is not case sensitive, be the job
>> of one of the authentication hooks? This is how we always
>> recommended fixing this issue in Horde 3. This would ensure that
>> the same username is *always* used, and would alleviate the need
>> for any of the above "fixes".
>
> Exactly, but this only applies if joe and Joe are the same in the
> authentication backend. The admins are responsible for normalizing
> user names if necessary. But *if* Joe and joe are indeed different
> users, we have to support that. At the moment this is not possible
> in these few places.
Ah. Silly me didn't account for the fact that joe and Joe may be
different users. Makes sense.
>>
>>
>>> Other places that might be affected:
>>> - group names
>>> - tag names (we already normalize them in php code)
>>> - vilma domain and user names
>>> - wiki page names
>>>
>>> Jan.
>>
>> Shouldn't this be handled by
>>
>>
>>
>>> Do you need professional PHP or Horde consulting?
>
> By what? Professional consulting? Sure :)
Heh, yeah... started replying here and must have forgot to delete it :)
> Jan.
>
> --
> Do you need professional PHP or Horde consulting?
> http://horde.org/consulting/
>
> --
> Horde developers mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
mike
The Horde Project (www.horde.org)
mrubinsk at horde.org
More information about the dev
mailing list