Hi Emmanuel, I can see now that you have already fixed the problem. We have M24 running now, how can I use your fix in our environment? Or otherwise how can I build the latest snapshot to be able to verify it?
Best regards Sergey Mikhno Software Developer Galexis AG On Tue, Apr 30, 2019 at 4:40 PM Emmanuel Lécharny <elecha...@gmail.com> wrote: > I have created a JIRA ticket for this issue: > https://issues.apache.org/jira/browse/DIRAPI-340 > > Incidentally, I also have a fix that I'm going to test and apply asap. > (the fix is pretty straightforward) > > > On 30/04/2019 16:29, Sergey Mikhno wrote: > > Thank you again, > > > > Is it possible to get a fix for this issue, how should we go about it? > > It would be great to be able to test a bugfix in our environment. > > > > Best Regards > > > > Sergey > > > > > > On Tue, Apr 30, 2019 at 4:24 PM Emmanuel Lécharny <elecha...@gmail.com> > > wrote: > > > >> 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? > >>>> > > > -- Sergey Mikhno
