Description of problem:
I define an index with:
dn: cn=uid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
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
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):
Steps to Reproduce:
shown in description.
Index is not used.
Index should be used.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see email@example.com with any questions
Automated tests pass
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?
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...
Automated test passed:
No errors logged:
# grep -c "invalid matching rule" /var/log/dirsrv/slapd-standalone/errors
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.