Le 10/04/16 20:07, Emmanuel Lécharny a écrit : > 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 :-) Forget about it.
Bottom line : there is no bad idea that can't be clarified by a good night sleep :-) LdapComparators are a good way to implement very specific order that is semantically distinct from the base order we use in an index. That would be impeding teh server not to have a way to extend the comparison of values in the filter or in something like the SSV control.
