>> Do you have a use case for this? I'm implementing add-if-not-present to >> ease the implementation of the version number overlay, so I could >> implement softdel as well. >> >> I think all of these could make sense also protocol-wise (including >> softadd), but I'm not in the mood right now to start the formalization >> process, so I'd leave it to a later time. > > Yes. I've had to implement this exact feature in application code before > (via search + conditional mod). It appears frequently in middleware stuff > when you're merging data from multiple upstream account sources and a > registry into LDAP. The softdel case appears less often than softadd, but > is extremely useful when trying to cleanup mistakes. > > More concretely, middleware performing a multi-db reconciliation sweep can > use it to assert implied constraints on each object. For example, if some > event happens, the entry must now have attr1=val1, and must not have > attr2=val2, but might already be in that situation. This allows for more > cases of idempotent atomic changes without needing transactions. > > A number of overlays will need to watch for this as it is particularly > relevant for groups (memberOf, refint, etc).
Sounds good. In principle, applications should be able to perform *most* of the operations by a proper combination of pre/post read, assert, and permissive controls, but in some cases they'll need more than one write operation, thus losing atomicity (until we have transactions, at least :). Internal/middleware is a different business, that's why I wanted to discuss this first on -devel. I've updated the patch to include "softdel" (SLAP_MOD_SOFTDEL) as well, although I didn't test it yet. I was going to complete the picture with a "del-if-present", but its semantics can be obtained using "softdel" with NULL values. At this point, I wonder whether it would make sense to support "softadd", "softdel" and "add-if-not-present" protocol-wise, as they allow more granularity than the permissive modify control. p.
