https://bugs.openldap.org/show_bug.cgi?id=9295
--- Comment #11 from Michael Ströder <[email protected]> --- On 5/29/21 11:46 AM, [email protected] wrote: > https://bugs.openldap.org/show_bug.cgi?id=9295 > > --- Comment #10 from Ondřej Kuzník <[email protected]> --- > On Fri, May 28, 2021 at 10:20:59PM +0000, [email protected] 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. Note before your next answer: ;-) Not every LDAP server supports assertion control or MOD_INCREMENT with read entry controls. Or even worse, some implementations of the assertion control are buggy... Ciao, Michael. -- You are receiving this mail because: You are on the CC list for the issue.
