Bug 1196282 - substring index with nssubstrbegin: 1 is not being used with filters like (attr=x*)
Summary: substring index with nssubstrbegin: 1 is not being used with filters like (at...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: 389-ds-base
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: pre-dev-freeze
: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-25 15:58 UTC by German Parente
Modified: 2020-09-13 21:21 UTC (History)
4 users (show)

Fixed In Version: 389-ds-base-1.3.5.7-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-03 20:34:46 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github 389ds 389-ds-base issues 1440 0 None None None 2020-09-13 21:21:27 UTC
Red Hat Product Errata RHSA-2016:2594 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2016-11-03 12:11:08 UTC

Description German Parente 2015-02-25 15:58:06 UTC
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:

Comment 1 Noriko Hosoi 2015-02-26 23:47:17 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/48109

Comment 9 Mike McCune 2016-03-28 23:12:48 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 11 Viktor Ashirov 2016-06-15 13:07:53 UTC
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?

Comment 12 Noriko Hosoi 2016-06-15 20:45:52 UTC
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.

Comment 13 Noriko Hosoi 2016-06-15 21:55:38 UTC
(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...

Comment 14 Viktor Ashirov 2016-06-28 08:18:16 UTC
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.

Comment 16 errata-xmlrpc 2016-11-03 20:34:46 UTC
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


Note You need to log in before you can comment on or make changes to this bug.