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

[Xi Sanderson]

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?

Thanks,

Xi