Hi,
i'm facing a strange problem. The client-api-test
ClientSearchRequestTest.testSearchPersonSubstring() is failing on
Selcuk's branch(with my modifications), and was working on Selcuk's
branch before my modifications. The search returns too more entries (the
filter tells the server to return all the entries with an Ojectclass
containing *ers* - person, for instance-, and we get 12 entries instead
of 3).
I have debugged the code most of the day, and the difference between
those two versions is that the previous version does not initiate a txn
when injecting the LDIFs into the server, when the new version does
(because it's using the coreSession).
OTOH, this should not be a problem at all : the newly added entries are
visible (using Studio), and the search is done after the modification.
As a matter of fact, when we are walking the cursors during the search,
up to a point, we read data from the txnIndexCursor in the new code,
when this cursor is null in the old code. I don't know well this part of
this cod, but my understanding is that this txnIndexCursor is supposed
to be used to read the data stored in the changeLog (ie, data which has
been modified but not flushed yet to the disk). IMO, even if the cursor
is not null, we shuld not grab element from it, but sadly, we do.
Here are the three changes done before the search :
[
IndexChange 'apacheRdn': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e,
ParentIdAndRdn<1e5c8c99-63d6-4218-8700-f61e420713aa, 'cn=user1'>>,
IndexChange 'objectClass': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e,
person>,
IndexChange 'objectClass': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e,
top>,
IndexChange 'apacheOneLevel': <ADD,
b881e633-e69c-43b5-905e-c731632f0f8e,
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD,
b881e633-e69c-43b5-905e-c731632f0f8e,
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD,
b881e633-e69c-43b5-905e-c731632f0f8e,
b881e633-e69c-43b5-905e-c731632f0f8e>,
IndexChange 'entryCSN': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e,
20120104194007.961000Z#000000#000#000000>,
IndexChange 'entryUUID': <ADD, b881e633-e69c-43b5-905e-c731632f0f8e,
b881e633-e69c-43b5-905e-c731632f0f8e>,
EntryAddDelete change : ADD
Entry
dn[n]: cn=user1,ou=users,ou=system
objectclass: person
objectclass: top
cn: user1
sn: user1 sn
entryParentId: 1e5c8c99-63d6-4218-8700-f61e420713aa
entryUUID: b881e633-e69c-43b5-905e-c731632f0f8e
creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
createTimestamp: 20120104194007Z
entryCSN: 20120104194007.961000Z#000000#000#000000
]
[
IndexChange 'apacheRdn': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
ParentIdAndRdn<1e5c8c99-63d6-4218-8700-f61e420713aa, 'cn=user1-alias'>>,
IndexChange 'objectClass': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
extensibleObject>,
IndexChange 'objectClass': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
alias>,
IndexChange 'objectClass': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
top>,
IndexChange 'apacheAlias': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
2.5.4.3=user1,2.5.4.11=users,2.5.4.11=system>,
IndexChange 'apacheOneLevel': <ADD,
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD,
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD,
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42>,
IndexChange 'entryCSN': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
20120104194128.727000Z#000000#000#000000>,
IndexChange 'entryUUID': <ADD, 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42,
9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42>,
EntryAddDelete change : ADD
Entry
dn[n]: cn=user1-alias,ou=users,ou=system
objectclass: extensibleObject
objectclass: alias
objectclass: top
aliasedobjectname: cn=user1,ou=users,ou=system
cn: user1-alias
entryParentId: 1e5c8c99-63d6-4218-8700-f61e420713aa
entryUUID: 9515c45d-1dbc-4bb5-bea0-7ecbcbec7e42
creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
createTimestamp: 20120104194128Z
entryCSN: 20120104194128.727000Z#000000#000#000000
]
[
IndexChange 'apacheRdn': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872,
ParentIdAndRdn<1e5c8c99-63d6-4218-8700-f61e420713aa, 'cn=elecharny'>>,
IndexChange 'objectClass': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872,
person>,
IndexChange 'objectClass': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872,
top>,
IndexChange 'apacheOneLevel': <ADD,
588509f4-ad9e-4aef-84a7-bee04e64b872,
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD,
588509f4-ad9e-4aef-84a7-bee04e64b872,
1e5c8c99-63d6-4218-8700-f61e420713aa>,
IndexChange 'apacheSubLevel': <ADD,
588509f4-ad9e-4aef-84a7-bee04e64b872,
588509f4-ad9e-4aef-84a7-bee04e64b872>,
IndexChange 'entryCSN': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872,
20120104194227.433000Z#000000#000#000000>,
IndexChange 'entryUUID': <ADD, 588509f4-ad9e-4aef-84a7-bee04e64b872,
588509f4-ad9e-4aef-84a7-bee04e64b872>,
EntryAddDelete change : ADD
Entry
dn[n]: cn=elecharny,ou=users,ou=system
objectclass: person
objectclass: top
cn: elecharny
sn: Emmanuel Lécharny
entryParentId: 1e5c8c99-63d6-4218-8700-f61e420713aa
entryUUID: 588509f4-ad9e-4aef-84a7-bee04e64b872
creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
createTimestamp: 20120104194227Z
entryCSN: 20120104194227.433000Z#000000#000#000000
]
When we fetch the candidate from the ObjectClass index, we will now get
tuple found from the backend, and tuples grabbed from the changes, and
both entries are returned to the client. At this point, I have no idea
what can go wrong... Any help would be greatly appreciated :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
