https://bugs.openldap.org/show_bug.cgi?id=9295

--- Comment #12 from Howard Chu <[email protected]> ---
(In reply to Michael Ströder from comment #11)
> 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.

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.

-- 
You are receiving this mail because:
You are on the CC list for the issue.

Reply via email to