Ok, this a clear bug. The UniqueMemberComparator.compare() method is
badly implemented, and returns either 0 or -1, which means we can't
browse the index, as we never get a +1 (ie, provided uniqueMember is
superior to the stored one).
I'll get that fixed.
On 30/04/2019 15:59, Emmanuel Lécharny wrote:
Hi Sergey,
I can positively confirm that there is a problem. I'm able to
reproduce the issue you are facing in a unit test.
I'm currently debugging the server, and hope to come with a quick
answer (and hopefully a fix).
On 30/04/2019 11:33, Sergey Mikhno wrote:
Dear Emmanuel,
I spent now more than a week trying to understand why uniqueMember index
doesn't work and still have no progress in understanding the problem.
With a defined index on uniqueMember my query brings empty result
*(**&*
*(*objectclass*=*groupOfUniqueNames*)*
*(**|*
*(*uniqueMember*=*cn=galexisLoginPOS*)*
*(*uniqueMember*=*cn=customerGalexis*)*
*(*uniqueMember*=*cn=customerAlloga*)*
*(*uniqueMember*=*cn=isDemo*)*
*)*
*)*
Without index the query brings correct results but is slow, 300ms.
Is there any description about how to define an index on uniqueMember.
We have several other non-standard indexed attributes and all of them
are
working.
As I understand it should be possible to define an index on both
member and
uniqieMember.
So I have 2 questions:
1. Is it correct that this query is slow because there is no index?
2. How should I define such an index?
Below is the current index definition
dn:
ads-indexAttributeId=uniqueMember,ou=indexes,ads-partitionId=system,ou=parti
tions,ads-directoryServiceId=default,ou=config
ads-indexHasReverse: FALSE
entryCSN: 20190430090357.476000Z#000000#001#000000
objectClass: ads-index
objectClass: top
objectClass: ads-jdbmIndex
objectClass: ads-base
createTimestamp: 20190430090357.476Z
creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
ads-indexAttributeId: uniqueMember
ads-enabled: TRUE
entryUUID: dcd2fa31-5ee0-48fb-9d3e-30487957045a
entryParentId: fdf6f3a6-dfaf-4b1a-962c-faa14328d1ae
Could you please advice?