On 10/8/07, Emmanuel Lecharny <email@example.com> wrote:
"A filter item evaluates to Undefined when the server would not be
able to determine whether the assertion value matches an entry.
- An attribute description in an equalityMatch, substrings,
greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
is not recognized by the server.
- The attribute type does not define the appropriate matching rule."
Right now ApacheDS uses the following algorithm:
1). Attempt to use the correct matchingRule for the the AVA in a search filter. For example
if SUBSTR matching is to be used ApacheDS will search for this first on the attribute
associated with the attribute identifier used in the AVA.
2). If it cannot find the matchingRule for the attribute the registries are used to find a SUBSTR
matchingRule on superior attributeTypes going up the ancestry of the AT.
3). If no matchingRule for the AVA type was found in the entire AT ancestry then equality
matching rules are used with the same tactic of checking from child up through the
Now #3 is an issue for several reasons. First of as you cleverly pointed out the EQUALITY
matchingRule may not work for several reasons but mainly because the attributeType's syntax
may not be a String. Also there are semantic issues with this.
We can fix this in 2 ways. First we can only take option #3 if the syntax is a syntax that
is human readable.
Or we can prune the filter leaving that AVA as undefined. When we pull search out of the partition
into the server we may want to look at making sure all the matchingRules are in place and resolved
for the filter AST before begining the search descent. At this point we can prune correctly.
I'd rather follow the spec exactly to the T so the later option is perhaps the best.
- How does other servers react with such searches ?
Yes I am curious about this too. Perhaps once I setup a lab I can look at this.
- Should we default to EqualityMatch if we don't have a matchingRule
for an AttributeType ?
Talked about this above.