If you have a view created which filters on a common attribute (l or ou for example), an ldapsearch against that view reports as 'unindexed' in the 'access' logs.
Ensuring that the search is only focused on indexed attributes, the result still shows up as 'unindexed'. Whether this is a reporting error or there are indeed internal calls going to the db, this shouldn't be marked as 'unindexed' if the search is going against all indexed attributes (including the attribute listed as the 'nsviewfilter').
Steps to Reproduce: 1. For simplicity, use the /usr/share/dirsrv/data/Example-views.ldif file and add that to an instance. This has 2 different views (one based off of 'ou' and one based off of 'l').
Ensure that the 'ou' and 'l' attributes are indexed in the userroot db with 'eq' and 'pres'. The 'objectclass' and 'cn' in the search in step #3 are already indexed.
Perform an ldapsearch similar to the following:
"ou=Accounting,ou=Functional,ou=Organization Views,dc=example,dc=com" objectclass=inetOrgPerson cn
Actual results: Within /var/log/dirsrv/slapd-INSTANCE/access:
[09/Oct/2012:13:15:15 -0700] conn=21 op=1 SRCH base="ou=Accounting,ou=Functional,ou=Organization Views,dc=example,dc=com" scope=2 filter="(objectClass=inetOrgPerson)" attrs="cn" [09/Oct/2012:13:15:15 -0700] conn=21 op=1 RESULT err=0 tag=101 nentries=41 etime=0 notes=U
Expected results: The search should be indexed, and if it is actually already an indexed search, it should be reported as such within the access log.
'''Here is the current status'''
- issue is reproducible
{{{ [30/Apr/2013:14:31:25 +0200] conn=2 op=1 SRCH base="ou=Accounting,ou=Functional,ou=Organization Views,dc=example,dc=com" scope=2 filter="(objectClass=inetOrgPerson)" attrs="cn" [30/Apr/2013:14:31:25 +0200] conn=2 op=1 RESULT err=0 tag=101 nentries=41 etime=0 notes=U }}}
- The view transforms the search (view_search_rewrite_callback) parameters (base, scope and filter) to
{{{ base = "dc=example,dc=com" scope = subtree filter = "(| (&(ou=Accounting)(!(objectclass=nsView))(objectClass=inetOrgPerson)) (&(objectClass=inetOrgPerson)(|(parentid=12)(entryid=12))) )"
"ou" : indexed in equality "objectclass" : indexed in equality "parentid" : indexed in equality "entryid" " not indexed
}}}
- "entryid" being not indexed in equality triggers notes=U
{{{ [30/Apr/2013:14:58:13 +0200] conn=9 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(|(&(ou=Accounting)(!(objectClass=nsView))(objectClass=inetOrgPerson))(&(objectClass=inetOrgPerson)(|(parentid=12)(entryid=12))))" attrs="distinguishedName" [30/Apr/2013:14:58:13 +0200] conn=9 op=1 RESULT err=0 tag=101 nentries=41 etime=0 notes=U }}}
The first part of the filter is indexed
{{{ [30/Apr/2013:14:46:49 +0200] conn=4 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(ou=Accounting)(!(objectClass=nsView))(objectClass=inetOrgPerson))" attrs=ALL [30/Apr/2013:14:46:49 +0200] conn=4 op=1 RESULT err=0 tag=101 nentries=41 etime=0 }}}
The second part of the filter is not indexed because of 'entryid'
{{{ [30/Apr/2013:15:00:20 +0200] conn=10 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=inetOrgPerson)(|(parentid=12)(entryid=12)))" attrs="distinguishedName" [30/Apr/2013:15:00:20 +0200] conn=10 op=1 RESULT err=0 tag=101 nentries=0 etime=0 notes=U
[30/Apr/2013:14:49:21 +0200] conn=6 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=inetOrgPerson)(parentid=12))" attrs=ALL [30/Apr/2013:14:49:21 +0200] conn=6 op=1 RESULT err=0 tag=101 nentries=0 etime=0
[30/Apr/2013:14:50:03 +0200] conn=7 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(entryid=12)" attrs=ALL [30/Apr/2013:14:50:03 +0200] conn=7 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U }}}
- If entryid is indexed in equality the view search becomes indexed dn: cn=entryid,cn=index,cn=userRoot,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: nsIndex nsSystemIndex: false cn: entryid nsIndexType: eq
{{{ [30/Apr/2013:15:03:41 +0200] conn=4 op=1 SRCH base="ou=Accounting,ou=Functional,ou=Organization Views,dc=example,dc=com" scope=2 filter="(objectClass=inetOrgPerson)" attrs="cn" [30/Apr/2013:15:03:41 +0200] conn=4 op=1 RESULT err=0 tag=101 nentries=41 etime=0
[30/Apr/2013:15:03:07 +0200] conn=3 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(|(&(ou=Accounting)(!(objectClass=nsView))(objectClass=inetOrgPerson))(&(objectClass=inetOrgPerson)(|(parentid=12)(entryid=12))))" attrs="distinguishedName" [30/Apr/2013:15:03:07 +0200] conn=3 op=1 RESULT err=0 tag=101 nentries=41 etime=0 }}}
- Something that looks weird is that the following search (before entryid index) reports 'notes=U' while objectclass equality index exists. So we have a candidate list for (objectClass=inetOrgPerson) and this search is not unindexed.
{{{ [30/Apr/2013:14:52:17 +0200] conn=8 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=inetOrgPerson)(entryid=12))" attrs=ALL [30/Apr/2013:14:52:17 +0200] conn=8 op=1 RESULT err=0 tag=101 nentries=0 etime=0 notes=U }}}
After indexing 'entryid' this search becomes indexed
{{{ [30/Apr/2013:15:11:53 +0200] conn=7 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(objectClass=inetOrgPerson)(entryid=12))" attrs=ALL [30/Apr/2013:15:11:53 +0200] conn=7 op=1 RESULT err=0 tag=101 nentries=0 etime=0 }}}
Here are the next steps
- When using views the attribute 'entryid' should be indexed in equality. On large DB, where 'objectclass=xxx' is likely to be unindexed, we really need to have an equality index for 'entryid' This should be documented - Investigate why the following search filter triggers notes=U (when entryid is not indexed) (&(objectClass=inetOrgPerson)(entryid=12)) in our case objectclass=inetOrgPerson is still indexed
{{{ [30/Apr/2013:15:19:43 +0200] conn=8 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(objectClass=inetOrgPerson)" attrs=ALL [30/Apr/2013:15:19:43 +0200] conn=8 op=1 RESULT err=0 tag=101 nentries=150 etime=0 }}}
Here is the current status
{{{ [30/Apr/2013:17:46:46 +0200] conn=10 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(l=Santa Clara)" attrs="distinguishedName" [30/Apr/2013:17:46:46 +0200] conn=10 op=1 RESULT err=0 tag=101 nentries=76 etime=0
[30/Apr/2013:17:47:36 +0200] conn=11 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(l=Santa Clara)(roomNumber=*))" attrs=ALL [30/Apr/2013:17:47:36 +0200] conn=11 op=1 RESULT err=0 tag=101 nentries=76 etime=0 notes=U
[30/Apr/2013:17:48:15 +0200] conn=12 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(roomNumber=*)(l=Santa Clara))" attrs=ALL [30/Apr/2013:17:48:15 +0200] conn=12 op=1 RESULT err=0 tag=101 nentries=76 etime=0 notes=U
[30/Apr/2013:17:48:47 +0200] conn=13 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(roomNumber=3445)(l=Santa Clara))" attrs=ALL [30/Apr/2013:17:48:47 +0200] conn=13 op=1 RESULT err=0 tag=101 nentries=1 etime=0 notes=U
[30/Apr/2013:17:49:14 +0200] conn=14 op=1 SRCH base="dc=example,dc=com" scope=2 filter="(&(roomNumber=34*)(l=Santa Clara))" attrs=ALL [30/Apr/2013:17:49:14 +0200] conn=14 op=1 RESULT err=0 tag=101 nentries=2 etime=0 notes=U }}}
The customer successfully verified that indexing 'entryid' fixes their issue. A documentation bug have been filled to update the admin guide (see related bug).
As there is no code change for this ticket, I am closing it.
Metadata Update from @tbordaz: - Issue assigned to tbordaz - Issue set to the milestone: 1.3.2 - 06/13 (June)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/653
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.