Red Hat Bugzilla – Bug 1196282
substring index with nssubstrbegin: 1 is not being used with filters like (attr=x*)
Last modified: 2016-11-03 16:34:46 EDT
Description of problem: I define an index with: nssubstrbegin: 1 like this: dn: cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex objectClass: extensibleObject cn: uid nsSystemIndex: false nsIndexType: eq nsIndexType: pres nsIndexType: sub nssubstrbegin: 1 nssubstrmiddle: 1 nssubstrend: 1 + db2index And a query with filter (uid=n*) seems not to be using the index: [25/Feb/2015:15:37:06 +0100] conn=7 op=1 SRCH base="o=redhat" scope=2 filter="(uid=n*)" attrs=ALL [25/Feb/2015:15:37:06 +0100] conn=7 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=A if I do dbscan I find keys having two or more chars but not one as expected. dbscan -f /var/lib/dirsrv/slapd-server2/db/userRoot/uid.db4 ... *^ne *^u1 *^ui *^us *_us ... Is this a limitation of libdb ? Could this be considered a bug ? Or minimum for nssubstrbegin should be 2 ? NOTE: a query using filter with two chars substring seems to use the index. [25/Feb/2015:14:50:36 +0100] conn=13 op=1 SRCH base="o=redhat" scope=2 filter="(uid=ne*)" attrs=ALL [25/Feb/2015:14:50:36 +0100] conn=13 op=1 RESULT err=0 tag=101 nentries=1 etime=0 Version-Release number of selected component (if applicable): 1.2.11.15-48 How reproducible: Always. Steps to Reproduce: shown in description. Actual results: Index is not used. Expected results: Index should be used. Additional info:
Upstream ticket: https://fedorahosted.org/389/ticket/48109
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Build tested: 389-ds-base-1.3.5.6-1.el7.x86_64 Automated tests pass tickets/ticket48109_test.py::test_ticket48109_0 PASSED tickets/ticket48109_test.py::test_ticket48109_1 PASSED tickets/ticket48109_test.py::test_ticket48109_2 PASSED tickets/ticket48109_test.py::test_ticket48109_final PASSED But after executing test_ticket48109_2 there are lines in the error log: [15/Jun/2016:09:05:26.659697616 -0400] from ldbm instance init: line 0: unknown or invalid matching rule "nssubstrbegin=3" in index configuration (ignored) [15/Jun/2016:09:05:26.661677136 -0400] from ldbm instance init: line 0: unknown or invalid matching rule "nssubstrend=3" in index configuration (ignored) Is this expected?
Thanks, Viktor. I have to admit the test case was wrong. I should not have added nsMatchingRule with the value nssubstr*=num. > dn: cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config > nsMatchingRule: nssubstrbegin=3 > nsMatchingRule: nssubstrend=3 I'm going to take it off. Reopening 48109.
(In reply to Noriko Hosoi from comment #12) > Thanks, Viktor. > > I have to admit the test case was wrong. I should not have added > nsMatchingRule with the value nssubstr*=num. > > dn: cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config > > nsMatchingRule: nssubstrbegin=3 > > nsMatchingRule: nssubstrend=3 > > I'm going to take it off. Reopening 48109. No, I was wrong... the test case itself is ok. #48109 patch had a bug...
Build tested: 389-ds-base-1.3.5.8-1.el7 Automated test passed: tickets/ticket48109_test.py::test_ticket48109 PASSED No errors logged: # grep -c "invalid matching rule" /var/log/dirsrv/slapd-standalone/errors 0 Marking as VERIFED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2016-2594.html