[dev] Case insensitive unique key, was: [horde] Error when updating DB scheme for kronolith

Ronan SALMON rsalmon at mbpgroup.com
Mon Apr 25 16:58:02 UTC 2011


Chuck Hagenbuch <chuck at horde.org> a écrit :

> 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)
>> - ???
>
> What about making Horde usernames case insensitive everywhere?
>
> I know that we have made a policy of not mucking with usernames, but  
> does anyone actually use case sensitivity to make joe and Joe  
> different accounts? It seems to cause a lot of confusion for people,  
> as well as posing problems like this one.

This could be a Horde configuration option, and by default set to  
insensitive username.

Ronan.


More information about the dev mailing list