[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: searching for >=
If integerOrderMatch is implemented in your version of OpenLDAP then you
probably have version 2.1.x. This is a good thing!
Assuming the above, there should be no issue with changing the schema.
iPlanet took a different approach and assumed that everything is a string
(or literal), and the matching rules apply to all attributes. I am not
saying that is a good or bad thing, but they do allow ordered matching on
all integer fields (read: you can do it in iPlanet, so it may not be such
a bad thing, but then you can do anything in iPlanet so this may not be a
valid argument).
For me, I need integerOrderMatch for uidNumber as that is how we have it
implemented in our schema and that is how we use it with iPlanet. There
isn't any other solution for us either.
-lon
> OK. This nearly answers my last. I guess the question remains whether
> the consequences of mucking with standard schema are severe. The
> compatability issue is pretty obvious. Any other issues to be aware
> of?
>
> Also, defining my own attribute type would not allow me to search on
> existing uidnumbers unless it somehow aliases those existing
> attributes. Any way to do that?
>
> Thanks,
>
> Mike
>
> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Hallvard B
> Furuseth
> Sent: Tuesday, February 11, 2003 12:04 PM
> To: Mike Denka
> Cc: openldap-software@OpenLDAP.org
> Subject: Re: searching for >=
>
> Mike Denka writes:
>> ldapsearch -x "(&(uidNumber>=20000)(objectclass=*))" uid uidNumber
>
> You must add
> ORDERING integerOrderingMatch
> after the EQUALITY rule for uidNumber in
> etc/openldap/schema/nis.schema. Or better, define your own attribute
> type with such an own ORDERING rule, so you won't have to hack the
> standard schema.
>
> --
> Hallvard