directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Dn/Rdn/Ava refactoring : results
Date Tue, 10 May 2016 16:40:12 GMT
A bit more information about the changes and their impact.

- first of all, I had to add a getNormalized() method in Value, because
we badly need it in the server (typically when we put values in
indexes). This is quite a trivial change, as we already compute the
normalized value, it was not exposed.

- The Rdn.compareTo() method is broken for Rdns with more than one Ava,
when the Ava's order is at play. Rdn1: "cn=a+sn=b" and Rdn2: "sn=b+cn=a"
are not seen as equals...

- Substring filters handling has to be completely reviewed. The problem
is that the String Preparation comes into play, when we simply use a
regexp in the server. As the StringPrep adds some extra spaces -
(cn=abc*def) is translated to initial -> " abc", final -> "def " -, this
does not work well with regexp.

- Undefined evaluation is not properly handled too. Typically, when an
Attribute does not have a MatchingRule, we end up with a NPE because we
now try to find the associated Normalizer. In this case, I'm now using a
NoOpNormalizer to avoid getting a NPE. In any case, we have to review
the search engine to handle undefined evaluations.

- otherwise, in many places in the server, the changes make it simpler
to deal with DN, RDN and values, thanks to teh compareTo and equals methods.

- Note that we don't have a Dn.compareTo() method. This is probably missing.

- I have changed the FilterParser, and it's broken. It has to be fixed,
something I'll work on soon.

More to come...

View raw message