[Fedora-directory-devel] ldapsearch with size limit (-z) doesn't work with OR filter and range search

[Rich Megginson]

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://lists.fedoraproject.org/pipermail/389-devel/attachments/20080930/def61e9c/attachment.bin