• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Fixed Option ID duplicate check needs to be case-sensitive

tyteen4a03

Well-known member
#1
If you attempt to change the casing of Option IDs (e.g thisismyid to ThisIsMyID), the system will tell you that that ID is already in use.

So far I can reproduce this behaviour in Option IDs and Addon IDs, I think it's universal.
 

Jeremy

Well-known member
#2
Strings are considered case insensitive by MySQL, so to properly 'fix' this, you'd have to do a lot of table editing. Not saying this couldn't be improved (see which phrase you are editing and see if the IDs match and just switch to newIdSyntax), but mentioning why its happening.
 

tyteen4a03

Well-known member
#3
Strings are considered case insensitive by MySQL, so to properly 'fix' this, you'd have to do a lot of table editing. Not saying this couldn't be improved (see which phrase you are editing and see if the IDs match and just switch to newIdSyntax), but mentioning why its happening.
Google gives me this:

Code:
SELECT * FROM `table` WHERE BINARY `column` = 'value'
 

Jeremy

Well-known member
#4
Google gave me something different (defining things as Binary in the table). It may prove troublesome in the code, but then again variables in PHP are case sensitive. Personally, I think the way it works now is correct because it can cause ambiquity:

superCoolAddonPaypal and supercooladdonpaypal

Do they refer to the same thing or something else entirely? But I do agree you should be able to change case and not have it yell at you.
 

tyteen4a03

Well-known member
#5
Google gave me something different (defining things as Binary in the table). It may prove troublesome in the code, but then again variables in PHP are case sensitive. Personally, I think the way it works now is correct because it can cause ambiquity:

superCoolAddonPaypal and supercooladdonpaypal

Do they refer to the same thing or something else entirely? But I do agree you should be able to change case and not have it yell at you.
I would assume they are treated differently because they allow capital letters. No point allowing two cases without being able to differentiate between the two.
 

Jeremy

Well-known member
#6
I would assume they are treated differently because they allow capital letters. No point allowing two cases without being able to differentiate between the two.
They would be treated differently. :) I think XenForo properly makes these case insensitive to avoid ambiguity (do I want the all lowercase on-off option or the camel case one?). I think your bug more or less relates to the fact that it won't let you change the case after the initial creation. If that's the case, the field shouldn't be editable.
 

Mike

XenForo developer
Staff member
#7
Just moving this to a future version. It's reasonable to fix itself, but it starts exposing other issues related to phrases so it needs a careful pass on the schema.

As it's easy enough to workaround (rename from xyz to xyz1 then to XYZ), we'll look at this in the future.
 

tyteen4a03

Well-known member
#8
Just moving this to a future version. It's reasonable to fix itself, but it starts exposing other issues related to phrases so it needs a careful pass on the schema.

As it's easy enough to workaround (rename from xyz to xyz1 then to XYZ), we'll look at this in the future.
Is this fixed in 1.2.0 Beta 2?