[Date Prev][Date Next]
>> 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.