So with this comparator missing we were defaulting to the use of lexographic comparisons on the INTEGER syntax when an index was built on the syntax?

Makes sense since the index needs to be ordered using the ORDERING comparator for the integerMatch matching rule.  Just curious if this is your conclusion as well.

Thanks,
Alex

On Tue, Jan 6, 2009 at 4:13 PM, Emmanuel Lecharny (JIRA) <jira@apache.org> wrote:

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

Emmanuel Lecharny resolved DIRSERVER-1296.
------------------------------------------

   Resolution: Fixed

Patch applied, and fix done : a IntegerOrderingComparator has been added and registred.

> integer attribute types are not compared correctly
> --------------------------------------------------
>
>                 Key: DIRSERVER-1296
>                 URL: https://issues.apache.org/jira/browse/DIRSERVER-1296
>             Project: Directory ApacheDS
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 1.5.4
>            Reporter: Lorenz Breu
>             Fix For: 1.5.5
>
>         Attachments: ComparableComparator.java, patch_SearchIT.txt, SearchIT.java
>
>
> When searching for entries that have attributes with the INTEGER syntax, the values are compared lexicographically, not numerically. This happens even if the ordering and equality types are explicitly set to their integer versions when injecting the attribute types into ADS.
> Example:
> dn: cn = foo, dc = example
> cn: foo
> integerAttribute: 435
> now a search using "(integerAttribute<=500)" will correctly return the entry....
> but a search using "(integerAttribute<=44)" will ALSO return the entry, which it clearly should not.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.