check Id equality while ignoring case.#725
check Id equality while ignoring case.#725zubaidit wants to merge 1 commit intospring-projects:mainfrom
Conversation
LDAP attribute names are case insensitive. however, they are case aware. figured this when I tried to implement an entry. Take this case, let us say we have an attribute named "Mobile" with capital M in LDAP, if we type: @Attribute(name="mobile") // small m String mobile; In fetching process, this is fine. attribute is mapped properly and mobile variable will store whatever value. However, during saving process, the condition !id.equals(that.id) will compare "mobile" to "Mobile", and it will assume these attributes are not the same. thus it will be treated as an attribute that should go to REPLACE LDAP operation. Now, using Replace to non existing attribute will add that attribute to the LDAP entry. so "mobile" should be added. but actually what happens is the same as when we fetch attributes. LDAP will treat replace the value and won't create a new attribute. What is the new value? it is the same as the original one, since value haven't been touched. This causes a meaningless LDAP REPLACE operations. Hope that is clear and makes sense :) Acknowledgement: Wouldn't figure this out without the help of my dear mentor Mosaed Alsharyan, and my friend Omar Alhamdan
|
Thanks for the PR, @AlzubaidiTurki, and the explanation. It seems the ideal solution would be for the application to do There's also the issue that changing the That said, I can see that having a case-insensitive read paired with a case-sensitive write may be disorienting, and a change may be worth considering. Are you able to add tests to the PR that demonstrate that the new behavior works with the arrangement you have indicated? |
|
Thank you Mr.@jzheaux. Thanks, |
LDAP attribute names are case insensitive. however, they are case aware. figured this when I tried to implement an entry.
Take this case, let us say we have an attribute named "Mobile" with capital M in LDAP, if we type:
In fetching process, this is fine. attribute is mapped properly and mobile variable will store whatever value. However, during saving process, the condition !id.equals(that.id) will compare "mobile" to "Mobile", and it will assume these attributes are not the same. thus it will be treated as an attribute that should go to REPLACE LDAP operation.
Now, using Replace to non existing attribute will add that attribute to the LDAP entry. so "mobile" should be added. but actually what happens is the same as when we fetch attributes. LDAP will treat replace the value and won't create a new attribute.
What is the new value? it is the same as the original one, since value haven't been touched. This causes a meaningless LDAP REPLACE operations.
Hope that is clear and makes sense :)