You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Emmanuel Lecharny (JIRA)" <ji...@apache.org> on 2019/06/25 14:50:00 UTC

[jira] [Resolved] (DIRSERVER-1414) Normalization is not handling correctly (buit this has no impact)

     [ https://issues.apache.org/jira/browse/DIRSERVER-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

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: https://issues.apache.org/jira/browse/DIRSERVER-1414
>             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
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@directory.apache.org
For additional commands, e-mail: dev-help@directory.apache.org