Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <325023742.1254602183969.JavaMail.jira@brutus>
Date: Sat, 3 Oct 2009 13:36:23 -0700 (PDT)
From: "Emmanuel Lecharny (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Created: (DIRSERVER-1414) Normalization is not handling
 correctly (buit this has no impact)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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.