Le 10/04/16 19:32, Emmanuel Lécharny a écrit : > Hi guys, > > still in the process on refactoring the Value, PrepareString, etc... > > I now have a complete (and fast !) implementation of a couple of > Normalizers using the new String Preparation, and I realize that > LdapComparators are pretty much useless : we already have the > compareTo() and equals() method in teh Value class, which leverage the > AttributeType MatchingRules to compare values : at this point, I thinkLet me > we don't need the comparator. > > I'll investigate that later, atm I'm completing the refactoring (I have > many normalizers that need some work, and many many tests that don't > work anymore ;-) > > Thanks ! Let me elaborate a bit.
There is a thing called Ordering Matching Rule, which is supposed to be used when we need to compare too values. If we assume that we define an index on an Attribute, we implicitely suppose that we are able to order the values. That means we should have an Ordering MatchingRule for this Attribute, which is very unlikely, assuming that the only attributes that have an ORDERING mathcing rule defined are : dnQualifier, createTimestamp, modifyTimestamp, pwdAccountLockedTime, pwdCheckQuality, pwdEndTime, pwdFailureTime, pwdLastSuccess, pwdStartTime, krb5PasswordEnd, krb5ValidEnd, krb5ValidStart Quite a few... Bottom line, OREDERING matching rules are mainly used to validate a filter that uses >= or <= : if the Attribute has an ORDERING matching rule, then this filter will be evaluated, otherwise it will resolve to Undefined. Let's go back to out need : we don't care about the Ordering Matching Rule when it comes to compare two values, we just use the normalized form of the values, and that's enough to order them. This will never be visible to the user anyway. This is why I do think that the LdapComparator is quite useless. But I may miss something :-)
