Issue 5772 - ONE LEVEL search fails to return sub-suffixes

[progier389]

Problem: ONE LEVEL scoped search fails to return sub-suffixes entries Reason: When such search is done, a one level search is done on the main suffix and base search are done on any matching sub-suffix. But main suffix is processed search (to ensure that parent entries are returned before children ones when searching subtree) and ldbm_back_search change the filter to (&(parentid=xxx)old_filter) so the filter test reject the entry on the sub-suffixes. Solution: Revert the backend list when doing one level search so that the sub-suffixes are processed first and restore the base dn for the main suffix. Alternative rejected: reset the filter when discivering a sub-suffix. Not so easy because filter is altered by the rewriteres. And systematic duplication is an useless overhead if there is no matching sub-suffixes (which is the usual case)

Issue: #5772

Reviewed by: @tbordaz, @droideck (Thanks!)

[progier389]

Not sure I fully understand what you mean. But I suspect it could lead to performance degradation in some cases: If we craft the filter, we are back at the original problem of order If we do not craft it, either we do not use the parentid index (but it will be inefficient for ldapsearch -b basedn -s one (objectclass=*)) Or we do generate the parentid candidate list and merge explicitly it with the filter list but this time ldapsearch -b basedn -s one (uid=foo)) will be slow if the basedn tree is flat With crafted filter, the filter optimization mechanism will compute the filter efficiently in both case (starting with parentid in first case and uid in second case)

[tbordaz]

Not sure I fully understand what you mean. But I suspect it could lead to performance degradation in some cases: If we craft the filter, we are back at the original problem of order If we do not craft it, either we do not use the parentid index (but it will be inefficient for ldapsearch -b basedn -s one (objectclass=*)) Or we do generate the parentid candidate list and merge explicitly it with the filter list but this time ldapsearch -b basedn -s one (uid=foo)) will be slow if the basedn tree is flat With crafted filter, the filter optimization mechanism will compute the filter efficiently in both case (starting with parentid in first case and uid in second case)

Sorry I was confusing. I was wondering if something like this could help

+        slapi_pblock_get(pb, SLAPI_SEARCH_TARGET_SDN, &target_sdn);
+        if (slapi_sdn_compare(slapi_entry_get_sdn_const(e->ep_entry), target_sdn) == 0) {
+            filter_exec = create_onelevel_filter(filter, e, managedsait);
+        } else {
+            filter_exec = filter;
+        }

[progier389]

There is no need to compare the sdn: if build_candidate_list scope is LDAP_SCOPE_ONELEVEL that mean that it is the main backend (so slapi_sdn_compare will be true). (For the sub-suffix backends the scope is LDAP_SCOPE_BASE The problem is slapi_pblock_set(pb, SLAPI_SEARCH_FILTER, filter_exec); that modify the global pblock (and impact next backends processing) the alternative is to reset SLAPI_SEARCH_FILTER to the SLAPI_SEARCH_FILTER_INTENDED before calling the subsuffix (but I am a bit wary because I remember that freeing the filter is a bit tricky)

[progier389]

Fixed the test case description

[progier389]

d261ea27c..407bdaa00 main --> main baf4fd400..33e99f980 389-ds-base-3.0 --> 389-ds-base-3.0 c9d18299a..dc0d81844 389-ds-base-2.5 --> 389-ds-base-2.5 f27f15445..9501c34df 389-ds-base-2.4 --> 389-ds-base-2.4