directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny (JIRA)" <>
Subject [jira] [Resolved] (DIRSERVER-1414) Normalization is not handling correctly (buit this has no impact)
Date Tue, 25 Jun 2019 14:50:00 GMT


Emmanuel Lecharny resolved DIRSERVER-1414.
       Resolution: Fixed
    Fix Version/s:     (was: 2.1.0)

This has probably been fixed with LDAP API 2.0 refactoring. A test has been added ({{testSearchSubstring2}}
in {{ClientSearchRequestTest}})

> Normalization is not handling correctly (buit this has no impact)
> -----------------------------------------------------------------
>                 Key: DIRSERVER-1414
>                 URL:
>             Project: Directory ApacheDS
>          Issue Type: Bug
>    Affects Versions: 1.5.5
>            Reporter: Emmanuel Lecharny
>            Priority: Minor
>             Fix For: 2.0.0.AM26
> Normalizers are attached to MatchingRules. An AttributeType might have up to three MR
(EQUALITY, ORDERING and SUBSTR). Normalization is always done using the EQUALITY MR, regardless
the MR used.
> This has an impact on the DN normalization, and AT normalization that is done very early
in the requests processing. We also stores a normalized form of each DN withing the LdapDN
data structure, to avoid a costly operation to take place when searching for a value.
> This is a good thing as far as the potential MR a AT can use are all using the same Normalizer,
but the first time we will have a MR using a different normalizer, the search will fail.
> Right now, I suggest we keep doing what we are doing, ie, using the EQUALITY MR as a
default. It's very unlikely that it will have an impact on the server.
> As a side note, one can wonder when do we have a different normalizer used for an AT,
and there is a clear use case : when using a approx filter, for instance, or a substr filter,
normalization can be different(we may use a phonetic normalization for the approx filter,
and the normalization can be different if we are using a SUBSTR MR too). So far, we are ok
as we don't support the approx filter...

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message