masarati(a)aero.polimi.it wrote: > I need to implement a modify operation whose semantics is "add if not > present", an add that only takes place if that attribute is not yet > present in the entry. > > I need it as an internal operation, so right now I wouldn't bother > formalizing it as an extension of the semantics of the modify operation. > Something like the SLAP_MOD_SOFTADD, which in turn consists in adding an > attribute value only if that value is not already present. > > I'd introduce a SLAP_MOD_ADD_IF_NOT_PRESENT flag and add code to support > it in all (well, most) backends/overlays that need to muck with modify > operation type. Sounds like you could do it with an Assertion Control (!(attr=*)).

> I need to implement a modify operation whose semantics is "add if not > present", an add that only takes place if that attribute is not yet > present in the entry. > > I need it as an internal operation, so right now I wouldn't bother > formalizing it as an extension of the semantics of the modify operation. > Something like the SLAP_MOD_SOFTADD, which in turn consists in adding an > attribute value only if that value is not already present. > > I'd introduce a SLAP_MOD_ADD_IF_NOT_PRESENT flag and add code to support > it in all (well, most) backends/overlays that need to muck with modify > operation type. > > Comments? Objections? p. It might be a good idea to have a SOFTDEL as well; both are useful for declarative modifications of data. Think of them in terms of: Soft Add: The attribute shall contain at least these values, but might have others Soft Del: The attribute shall contain none of these values, but might have others Ideally as modify sub-operations.

Are you really trying to achieve a MOD_ADD_IF_NOT_PRESENT or don't fail adding an attribute or value if the value is already present ? MS AD has a PERMISSIVE MODIFY CONTROL that remove the ADD/DELETE constraints on the attributes and values, so that adding an attribute that exist will succeed but do nothing and similarly deleting an attribute or value that is not present succeed.

Ludovic Poitou wrote: > Are you really trying to achieve a MOD_ADD_IF_NOT_PRESENT or don't fail adding an attribute or value if the value is already present ? > > MS AD has a PERMISSIVE MODIFY CONTROL that remove the ADD/DELETE > constraints on the attributes and values, so that adding an attribute that exist will succeed but do nothing and similarly deleting an attribute or value that is not present succeed. Funny you should mention that. We support this control as well.

I didn't get the impression that that was the goal here. It sounded to me like "add this value unless *any* value is present" not "add this value if *this value* is not present"...

> My 2 cents. > > Ludovic. > > > > > On May 26, 2010, at 3:53 PM, masarati(a)aero.polimi.it wrote: > >>>> I need to implement a modify operation whose semantics is "add if not >>>> present", an add that only takes place if that attribute is not yet >>>> present in the entry. >>>> >>>> I need it as an internal operation, so right now I wouldn't bother >>>> formalizing it as an extension of the semantics of the modify operation. >>>> Something like the SLAP_MOD_SOFTADD, which in turn consists in adding an >>>> attribute value only if that value is not already present. >>>> >>>> I'd introduce a SLAP_MOD_ADD_IF_NOT_PRESENT flag and add code to support >>>> it in all (well, most) backends/overlays that need to muck with modify >>>> operation type. >>>> >>>> Comments? Objections? p. >>> >>> It might be a good idea to have a SOFTDEL as well; both are useful for >>> declarative modifications of data. Think of them in terms of: >>> >>> Soft Add: The attribute shall contain at least these values, but might >>> have others >>> Soft Del: The attribute shall contain none of these values, but might have >>> others >>> >>> Ideally as modify sub-operations. >> >> I'm not sure I understand how SOFTDEL differs from LDAP_MOD_DELETE. Do >> you mean that values listed in SOFTDEL will be deleted if they exist, or >> otherwise ignored? >> >> p. >> > > --- > Ludovic Poitou Sun Microsystems Inc. > OpenDS Community Manager Directory Services > http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France > > OpenDS, the Java LDAP Directory Server > http://www.opends.org > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

> Soft Del: The attribute shall contain none of these values, but might have > others

I'm not sure I understand how SOFTDEL differs from LDAP_MOD_DELETE. Do you mean that values listed in SOFTDEL will be deleted if they exist, or otherwise ignored?

>> Soft Del: The attribute shall contain none of these values, but might >> have >> others > I'm not sure I understand how SOFTDEL differs from LDAP_MOD_DELETE. Do > you mean that values listed in SOFTDEL will be deleted if they exist, or > otherwise ignored? Yes; LDAP_MOD_DELETE requires that the listed values exist. The delete-all-values case is separate. If we had cn: a cn: b and ran changetype: modify softdel: cn cn: b cb: c Then the result would be success and cn=a remaining. Yes, this is useful!

> 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).