directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: LdapComparator
Date Mon, 11 Apr 2016 07:54:58 GMT
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.



Mime
View raw message