[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
AW: WG: how to search for custom attribute-types
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: AW: WG: how to search for custom attribute-types
- From: "Nick Laqua" <Nick.Laqua@newtron.net>
- Date: Mon, 29 Apr 2002 08:58:04 +0200
- Cc: <openldap-bugs@OpenLDAP.org>
- Content-class: urn:content-classes:message
- Thread-index: AcHtRwLqKvZyi4bMTCirTYw1+gy0IgCAcUpA
- Thread-topic: WG: how to search for custom attribute-types
Hi Kurt,
in the meantime, I found out, that it was indeed a mistake in the schema, thanks for answering anyway.
Nick
-----Ursprüngliche Nachricht-----
Von: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Gesendet: Freitag, 26. April 2002 19:23
An: Nick Laqua
Cc: openldap-bugs@OpenLDAP.org
Betreff: Re: WG: how to search for custom attribute-types
At 01:02 PM 2002-04-15, Nick Laqua wrote:
>I don't know if this is a bug or some mistake on my side, but I can't find an error in the filter definition
It is likely not a bug. It is more likely that the schema may
not allow the assertion you make. I suggest you take this
to the software list. Be sure to provide the definition of
the attribute along with the message.
Kurt
>
>Nick
>
> -----Ursprüngliche Nachricht-----
> Von: Nick Laqua
> Gesendet: Fr 12.04.2002 18:41
> An: 'openldap-software@openldap.org'
> Cc:
> Betreff: how to search for custom attribute-types
>
>
>
> Hi all,
>
> We set up an openldap-server (2.0.23) on solaris using an oracle sql backend. We are using some custom object classes containing custom attribute types.
>
> When issuing search statements like the one below, we are told that we are using a bad filter (logfile):
>
> filter=(&(objectClass=*)(smartiSupplier=10))
>
> output (logfile):
>
> do_search
> ber_scanf fmt ({aiiiib) ber:
> ber_dump: buf=0x00167bc0 ptr=0x00167bc3 end=0x00167c19 len=86
> 0000: 63 54 04 1b 64 63 3d 77 65 62 65 64 69 2c 64 63 cT..dc=webedi,dc
> 0010: 3d 6e 65 77 74 72 6f 6e 2c 64 63 3d 6e 65 74 0a =newtron,dc=net.
> 0020: 01 02 0a 01 00 02 02 27 10 02 02 01 2c 01 01 00 .......'....,...
> 0030: a0 22 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 a3 "..objectclass.
> 0040: 13 04 0e 73 6d 61 72 74 69 53 75 70 70 6c 69 65 ...smartiSupplie
> 0050: 72 04 01 31 30 00 r..10.
> SRCH "dc=webedi,dc=newtron,dc=net" 2 0 10000 300 0
> begin get_filter
> AND
> begin get_filter_list
> begin get_filter
> PRESENT
> ber_scanf fmt (o) ber:
> ber_dump: buf=0x00167bc0 ptr=0x00167bf5 end=0x00167c19 len=36
> 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 a3 13 04 ..objectclass...
> 0010: 0e 73 6d 61 72 74 69 53 75 70 70 6c 69 65 72 04 .smartiSupplier.
> 0020: 01 31 30 00 .10.
> end get_filter 0
> begin get_filter
> EQUALITY
> ber_scanf fmt ({oo}) ber:
> ber_dump: buf=0x00167bc0 ptr=0x00167c02 end=0x00167c19 len=23
> 0000: a3 13 04 0e 73 6d 61 72 74 69 53 75 70 70 6c 69 ....smartiSuppli
> 0010: 65 72 04 01 31 30 00 er..10.
> end get_filter 0
> end get_filter_list
> end get_filter 0
> filter: (&(objectClass=*)(badfilter))
> ber_scanf fmt ({v}}) ber:
> ber_dump: buf=0x00167bc0 ptr=0x00167c17 end=0x00167c19 len=2
> 0000: 30 00 0.
> attrs:
> conn=0 op=7 SRCH base="dc=webedi,dc=newtron,dc=net" scope=2 filter="(&(objectCla
> ss=*)(badfilter))"
>
>
>
>
> As soon as we are using well-known attributes like cn or mail, or change the original filter like below, everything works fine:
>
> filter=(&(objectclass=*)(smartiSupplier=*))
>
> In the last case, obviously a PRESENT Filter (LDAP_FILTER_PRESENT) is used instead of an EQUALITY Filter (LDAP_FILTER_EQUALITY) and then it works although the same custom attribute is used (smartiSupplier).
>
> any idea ?
>
> Nick