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.
masarati@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=*)).
masarati@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=*)).
Well, I already considered the possibility to combine already existing semantics; however, there are two good reasons not to use that:
1) if the assertion fails, the operation needs to be resubmitted
2) there might already be an assertion control on the request
p.
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.
Matthew Backes Symas Corporation mbackes@symas.com
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.
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.
My 2 cents.
Ludovic.
On May 26, 2010, at 3:53 PM, masarati@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
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.
Thanks. OpenLDAP supports that control, but
1) it's not the exact semantics I'm looking for, and
2) I don't want to use controls in internal operations, because they may conflict with the semantics of the original operation (the control could be already present, or adding the control would affect other parts of the operation).
p.
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@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
On May 26, 2010, at 11:10 PM, Howard Chu wrote:
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've just added support for this control in OpenDS 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"...
Ok, I haven't paid too much attention at the full thread. But, personally I would be reluctant to extend the protocol (modification types) to cover use cases that are very close to existing solutions. But hey, OpenLDAP is not my product / project ;-)
Regards,
Ludo
My 2 cents.
Ludovic.
On May 26, 2010, at 3:53 PM, masarati@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/
--- 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
On May 26, 2010, at 11:10 PM, Howard Chu wrote:
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've just added support for this control in OpenDS 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"...
Ok, I haven't paid too much attention at the full thread. But, personally I would be reluctant to extend the protocol (modification types) to cover use cases that are very close to existing solutions.
Well, in fact ttis is not our current intention; I'm only considering this extension for internal, "middleware" operations. However, permissive modify control does not deal with the use case that originated this discussion, and moreover its design is flawed, because it applies to all modifications, while more granularity would be more useful.
But hey, OpenLDAP is not my product / project ;-)
well, it's everybody's :)
p.
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!
Matthew Backes Symas Corporation mbackes@symas.com
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!
Protocol-wise, this is what permissive modify control is intended for. I concur that having this as an internal modification (much like SLAP_MOD_SOFTADD) would allow finer grain control to internal operations, without (ab)using the permissive control. The same, in terms of granularity, applies protocol-wise.
p.
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.
p.
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).
Matthew Backes Symas Corporation mbackes@symas.com
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.
-
Howard Chu -
Ludovic Poitou -
masarati＠aero.polimi.it -
Matthew Backes