[Fedora-directory-devel] ldapsearch with size limit (-z) doesn't work with OR filter and range search
Rich Megginson
rmeggins at redhat.com
Tue Sep 30 20:13:50 UTC 2008
Xi Sanderson wrote:
> Hi,
>
> I am having a problem with the following command:
>
> ldapsearch -z 10 ...
> (&(attr1=val1)(|(attr2=val21)(attr2=val22))(attr3>=val3))
>
> The command returns successfully with 0 entry. I know there are
> entries in my database matching the search criteria. And if I remove
> "-z 10" option, all the entries matching the search criteria return.
> More interestingly, if I switch the order of the search filter:
>
> ldapsearch -z 10 ...
> (&(attr1=val1)(attr3>=val3)(|(attr2=val21)(attr2=val22)))
>
> It returns 10 entries. After looking at the fedora-ds-base code, I
> found the following:
>
> Range search ">=" or "<=" calls index_range_read() function, which has
> the following code:
>
> if (!is_and)
> {
> slapi_pblock_get(pb, SLAPI_SEARCH_SIZELIMIT, &sizelimit);
> }
>
> When filter is not AND, client side size limit is used to filter
> candidates. I don't understand why client side size limit is used on
> server side to filter the candidates in the first place.
>
> Now "is_and" is set in list_candidates() every time when it is called
> and it is called for AND and OR filters. So if I have a filter like this:
>
> (&(attr1=val1)(|(attr2=val21)(attr2=val22))(attr3>=val3))
>
> Since OR "|" is after AND "&", "is_and" is false when
> index_range_read() is called, size limit is used and if the candidates
> within the size limit don't satisfy the whole search criteria, no
> record is returned from the search. The code doesn't seem to
> understand OR is only for "(|(attr2=val21)(attr2=val22))" part of the
> filter.
>
> However, if I switch the filter order to:
>
> (&(attr1=val1)(attr3>=val3)(|(attr2=val21)(attr2=val22)))
>
> Now "is_and" is true when index_range_read() is called, thus no size
> limit is used and the records satisfy the search criteria are returned.
>
> Has anybody experienced same problem or know if there is an existing
> bug for this problem?
Sounds like a bug. Please file one at bugzilla.redhat.com against
Fedora Directory Server.
>
> Thanks,
>
> Xi
>
>
> --
> Fedora-directory-devel mailing list
> Fedora-directory-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20080930/def61e9c/attachment.bin>
More information about the Fedora-directory-devel
mailing list