* I wrote:
> See #374962 for an example where OpenLDAP appears to be doing schema
> checks between the add and delete, rather than on the combined operation
> (in this example combined with an attribute type that ignores
> whitespace, which ldapvi is not aware of).
Okay, after discussion with Gerfried Fuchs:
- the problem in #374962 might have been just that ldapvi was doing
an `add' followed by `delete' rather than vice versa
- my original reason for this patch was a report that the delete/add
method caused problems with iPlanet in a multimaster configuration
(?!), but I never received more information on that
- when offering an option for the old behaviour of using delete/add,
we will need to take care not to break the workaround for users that
depend on the order of attribute values as requested in:
http://lists.askja.de/pipermail/ldapvi/2007-May/000021.html
For the scenario where multiple users change the same entry, delete/add
compared to replace could offer two distinct advantages:
i) error instead of unintentional overwriting of the other
"simultaneous" write operation
ii) no conflict at all with "simultaneous" changes to values of the same
multi-valued attribute if those values were not touched by the
current operation
ldapvi originally tried to achieve ii) by using delete/add only for the
values that were changed.
We could instead aim for i) and still keep the old ordering by
performing a `delete' for every value seen previously, and then `add'
for each new value in the desired order.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
