1. 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

Discussion in 'Resolved Bug Reports' started by tyteen4a03, May 22, 2013.

  1. tyteen4a03

    tyteen4a03 Well-Known Member

    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.
     
    Jon W likes this.
  2. Jeremy

    Jeremy XenForo Moderator Staff Member

    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 likes this.
  3. tyteen4a03

    tyteen4a03 Well-Known Member

    Google gives me this:

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

    Jeremy XenForo Moderator Staff Member

    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.
     
  5. tyteen4a03

    tyteen4a03 Well-Known Member

    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.
     
  6. Jeremy

    Jeremy XenForo Moderator Staff Member

    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.
     
    tyteen4a03 likes this.
  7. Mike

    Mike XenForo Developer Staff Member

    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.
     
    Bob, tyteen4a03 and Jeremy like this.
  8. tyteen4a03

    tyteen4a03 Well-Known Member

    Is this fixed in 1.2.0 Beta 2?
     
  9. Mike

    Mike XenForo Developer Staff Member

    Yeah, though sort of indirectly from what you were asking. :)
     
    SneakyDave likes this.

Share This Page