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=ldbm 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 -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA Division FAX: 303-415-9702 3380 Mitchell Lane orion@xxxxxxxxxxxxx Boulder, CO 80301 http://www.cora.nwra.com -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
