On Aug 20, 2007, at 12:32 PM, Howard Chu wrote:
Donn Cave wrote:
On Aug 10, 2007, at 2:16 PM, Howard Chu wrote:
Now fixed in HEAD, please test.
Aug 10 15:06:55 rufus03 slapd[31488]: null_callback : error code 0x14 Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 be_modify (20) Aug 10 15:06:55 rufus03 slapd[31488]: syncrepl_entry: rid=101 be_modify failed (20) I could put some more research into this, but tell me if this doesn't make sense. Suppose this mysteriously swapped order: a,b,... b,a,... Your fix increments the first list's index, so next iteration it's b,... b,a,... which is fine, but next iteration is ... a,... "a" looks new at this point, and I try to add it, but it isn't new - we just forgot that it was in "old" - and I get error 0x14 (LDAP_TYPE_OR_VALUES_EXISTS)
OK, this should be working now.
No joy here. Arguably worse - I think you will find that this one will fail for same-order cases where the original code worked.
1. a,b x,b -> del a, ++i 2. b x,b -> ++i, add x, ++j 3. () b -> add b (oops, b already present.)
It looks easy enough to me to code up an order independent version that will actually work. I would initialize adds[] and dels[] with old & new berval pointers, iterate through dels[] and adds[] (nested), and clear both on match. The code is easier to follow and empirically I see one fewer matches in the cases I tested it on. But that's just a test of the algorithm - I haven't sorted out what needs to be done at the end of the function where mcur etc. are modified depending on i == j.
Donn Cave, donn@u.washington.edu