I might have missed something in the discussion, but even if
numsubordinates is indexed only with presence:

# dbscan -f numsubordinates.db4* -n -r

+************************************** 3

*** 1 3 4


the range search should return the expected result:

$ ldapsearch [...] -b "dc=example,dc=com" "(&(numsubordinates=*)(numsubordinates>=1))"
numsubordinates entryid

dn: dc=example,dc=com

numsubordinates: 4

entryid: 1



dn: ou=Groups,dc=example,dc=com

numsubordinates: 4

entryid: 3



dn: ou=People,dc=example,dc=com

numsubordinates: 2

entryid: 4




Rich Megginson wrote:

On 01/05/2011 11:39 AM, Orion Poplawski wrote:


On 01/05/2011 09:55 AM, Rich Megginson wrote:


On 01/05/2011 09:16 AM, Orion Poplawski wrote:


On 01/05/2011 09:06 AM, Rich Megginson wrote:


Try doing the ldapsearch you used to test, but add numSubordinates
to the list
of attributes to return:

ldapsearch .... "big filter with (numSubordinates>=1) clause
removed" *
numSubordinates



Okay, something is wrong here. These results appear correct:


Looks like a problem with the numSubordinates index - it looks like
it is only
indexed for presence - try adding an equality index for
numSubordinates and
reindex.

I don't know when or why this changed - looks like a regression.



I added an index for equality by adding nsIndexTypes: eq to:

cn=numsubordinates,cn=index,cn=userRoot,cn=ldbm
database,cn=plugins,dn=config
cn=numsubordinates,cn=index,cn=NetscapeRoot,cn=ldb m
database,cn=plugins,dn=config
cn=numsubordinates,cn=default indexes,cn=config,cn=ldbm
database,cn=plugins,dn=config

I triggered an index rebuild by adding:


dn: cn=db2index_2011_1_5_11_21_50, cn=index, cn=tasks, cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: db2index_2011_1_5_11_21_50
nsInstance: userRoot
nsIndexAttribute: numsubordinates:eq


Saw in the error log:

[05/Jan/2011:11:30:26 -0700] - userRoot: Indexing attribute:
numsubordinates
[05/Jan/2011:11:30:27 -0700] - userRoot: Finished indexing.

But now my numSubordinates>=1 search comes up empty. Interestingly,
numSubordinates>4 doesn't work either, but in this case it returns
all, even those with numSubordinates <= 4.

Restarting the slapd process didn't help.

Filed https://bugzilla.redhat.com/show_bug.cgi?id=667488


What does dbscan say?
dbscan -f /var/lib/dirsrv/slapd-instancename/db/userRoot/numsubordinates.db4
?

--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users






--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users