https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #12 from Howard Chu hyc@openldap.org --- (In reply to Michael Ströder from comment #11)
On 5/29/21 11:46 AM, openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #10 from Ondřej Kuzník ondra@mistotebe.net --- On Fri, May 28, 2021 at 10:20:59PM +0000, openldap-its@openldap.org wrote:
The way we munge the inbound op can backfire on operations like this:
add: singlevalued singlevalued: new - delete: singlevalued singlevalued: oldArguably, applications that do this are strange, but the protocol allows this and it's accepted on the provider.
Note that it's not strange at all: This is the recommended client behaviour when using an ID pool entry for unique ID assignment.
I'm not sure what the difference is to just sending a delete, then add from application's point of view? I know it shouldn't matter as the entry only needs to be consistent/valid when the operation is finished, but you're saying there are reasons to do just this...
Deleting certain attribute values makes sure that the entry you're modifying still has its former state. So this uses the ACID properties of a single modify operation as a test-and-set operation.
Most common example is ID assignment with an ID pool entry. You want to make sure that no other LDAP client consumed the next ID in between your last read and current ID update attempt.
My web2ldap also does this since many years to provoke write conflicts if users modified the same entry. And yes, it looks into subschema to determine whether the attributes have EQUALITY matching rule defined.
What you're describing is indeed routine. But the usual sequence is for the delete to come before the add. Even though it should make no difference in the end, it is unusual to do the add before the delete.