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 mmccune 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.