> The way we munge the inbound op can backfire on operations like this: > > ``` > add: singlevalued > singlevalued: new > - > delete: singlevalued > singlevalued: old > ``` > > Arguably, 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.

On 5/29/21 11:46 AM, openldap-its(a)openldap.org wrote: > https://bugs.openldap.org/show_bug.cgi?id=9295 > > --- Comment #10 from Ondřej Kuzník <ondra(a)mistotebe.net&gt; --- > On Fri, May 28, 2021 at 10:20:59PM +0000, openldap-its(a)openldap.org wrote: >>> The way we munge the inbound op can backfire on operations like this: >>> >>> ``` >>> add: singlevalued >>> singlevalued: new >>> - >>> delete: singlevalued >>> singlevalued: old >>> ``` >>> >>> Arguably, 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.