[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: searching for >=
Lon,
Thanks for the tip. I found a couple of threads explaining that, in
order to use the ">=" and "<=" operators, the context for the matching
rules on the attribute your searching for had to include "ORDERING".
The only context for uidNumber is EQUALITY. So I added the ORDERING
context and the 'integerOrderingMatch' matching rule to the uidNumber
attribute in nis.schema on a test machine. Then my search worked.
But I don't know if that's a wise change to make on a production LDAP
server. From what I could gather from one thread, the proper solution
would be to create a sub-attribute to uidNumber with an ORDERING context
and an "integerOrderingMatch" match rule in the schema. I'm not sure
how to do that. But does that seem like the best approach? Or is
changing the uidNumber attribute in nis.schema relatively harmless? I
wonder what price one would pay (in terms of performance, compatability,
etc.) if the uidNumber attribute were changed in nis.schema.
Thanks,
Mike
-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Lon Tierney
Sent: Tuesday, February 11, 2003 11:17 AM
To: mdenk@whidbey.net
Cc: openldap-software@OpenLDAP.org
Subject: Re: searching for >=
It depends what version of OpenLDAP you are using. Version 2.0.x doesn't
implement everything needed for searching with integers. Look for this
very discussion in the archives (Nov or Dec?).
In short, version 2.1 works great.
> According to the RFC and the man pages one should be able to search
for
> a range of numbers using the ">=" and "<=" operators. In my case, I
> need to know the uidNumbers that are greater than 20000. So I phrase
> my search as:
>
> ldapsearch -x "(&(uidNumber>=20000)(objectclass=*))" uid uidNumber
>
> This query returns no entries even though I know that I have at least
> 600 uidNumbers above 20000. I've tried as many variations on this
> pattern as I can think of and still no entries found.
>
> Anyone know what I'm doing wrong with this search string?
>
> Thanks,
>
> Mike