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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-devel