Bug 515329 - Correct attribute value inconsistency on replica

When performing operations with multiple mods to the same multi-valued
attribute on a single modify operation, a replica was not resolving
the attribute values correctly.  This would lead to an inconsistency
between the master the change was initially performed against and the
replicas.  The problem would occur with a modify operation such as
this:

  dn: uid=testuser,dc=example,dc=com
  changetype: modify
  add: cn
  cn: 2
  -
  replace: cn
  cn: 3

The problem is that we use the CSNs from the attribute state data
to determine which values should remain after the operation (this is
done to merge with later occuring changes from other masters).  The
CSN for all mods within the same modify operation is exactly the same.
The old code was looking for attributes older than the deletion that
occurs as a part of the replace, then deleting those values.  This
would cause the value of "2" in the above example to remain.  Simply
changing this comparision to look for values with the same or older
CSN to delete would cause the new value of "3" to be removed as well
when we get around to resolving the attribute after the second half
of the replace operation.

The fix is to use a different CSN comparison when we are removing all
values of an attribute during attribute resolution (remove values with
the same or older CSN).  This is safe becuse the only present values
at this time are older values or values added in a previous mod in the
same modify operation.  When processing other mods that are not
removing all values of an attribute, we only want to remove values
with a CSN older that that of the current modify operation.  This
prevents us from removing a newly added value, such as "3" in the
example above.  This is safe since we resolve the attribute after
each mod in the modify operation.

0 files changed, 0 insertions, 0 deletions