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

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DIRSERVER-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761952#action_12761952 ] 

Emmanuel Lecharny commented on DIRSERVER-1414:
----------------------------------------------

a good example of a potential problem where we use different Normalizer for the same attribute, when using different Matching rule, would be for a Name :

(cn=Test this)

In this case, we will use the EQUALITY MR, which will remove spaces on the left, right, and replace contiguous spaces inside the body by a second space.It also lowercase the value This filter will correctly match :
"  test     ThiS  "

Now, using a SUBSTR matching rule, the filter

(cn=Test *)

will match
" test   ThiS " but not necessarily "test", as the normalizer might keep the useless space before the '*' or keep it (and in this case, 'test' won't match)

This is just an exemple of potential bad matching, even if it won't happen with the CN attributes, as this AT does not define a SUBSTR MR...

> 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.5.0
>
>
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.