S-RAMP's update, updateContent, delete, and deleteContent actions

[brmeyer]

Lately, I've been working on better supporting update, updateContent, delete, and deleteContent.  As such, I'm thinking through exhaustive constraints and logic that would 1.) guarantee data integrity and 2.) allow these actions to work cleanly.  Here's what I've come up with so far:

UPDATE (note: metadata only)

• Prevent the UUID from changing
• No need to check relationships targeting this artifact

DELETE

• Block the action if any generic or modeled relationships target this artifact or any of its derived artifacts ("referential constraint")
• Derived relationships (ie, automatically generated and not editable by clients, such as importsXsds) targeting this artifact should be automatically removed, if all other constraints pass.

UPDATE CONTENT

• A content update has the potential to change a primary artifact's set of derived artifacts.  I was thinking that the derived artifacts would be deleted (not trashed, but completely removed), then regenerated.
• If generic/modeled relationships target any of the derived artifacts, block the update.
• Derived relationships will be regenerated on the primary artifact.
  
• In addition, if any custom properties or classifiers are attached to a derived artifact, block the update.  This is to protect clients from unknowingly deleting custom metadata, plus it furthers the "impact analysis" concept.

DELETE CONTENT

• This has the potential to be the most complicated discussion.  At first glance, the action seems pointless -- a document artifact should never be without content.  However, the spec allows document artifacts to be created in two shots: one to create the metadata and one to populate its content.  Therefore, a content-less state is possible and must be supported.
• If generic/modeled relationships target any of the derived artifacts, block the delete.

NOTES

• When looking for relationships that target the artifact in question, only the root tree is considered.  Ie, if a relationship source is deleted and moved to the trash, its relationships do not necessarily have to be removed (nor should they).
• Relevant JIRAs: [SRAMP-601] Support deleting an artifact's content - JBoss Issue Tracker, [SRAMP-541] Tighten the restrictions on artifact content updates - JBoss Issue Tracker, probably others

Thoughts?

I already have some of the constraint queries in place.  However,  once we've nailed down the definitive rules, I'll switch to a test-first approach and make sure all bases are covered.

[virchete]

Delete: --> Derived artifacts. As they depends on the parent reference. If the parent is deleted, i consider they should be deleted. This maybe can be the default, and can be changed throw properties.

UpdateContent --> I consider if the content is updated, the derived artifacts should be deleted.

DeleteContent --> The same logic.

[eric.wittmann]

For DELETE it seems like derived relationships should just be removed or "broken" in some way.  So +1 for that.

I think UPDATE CONTENT would be more powerful if you diff'd the new derived content with the old, and made changes instead of doing a simple delete+re-create.  It'd be harder to implement, but it would allow simple changes to be made to documents without worrying about killing off some set of custom meta-data changes made to the derived artifacts.  Note that this also includes custom properties and classifiers, not just relationships.  For example, a document is added and then content is derived from it.  Later, a user adds custom properties and/or classifiers to a subset of the derived artifacts.  If an update to the primary simply deletes all the derived content and regenerates it, all of that custom meta-data is lost.

For DELETE CONTENT, I think the derived content *is* explicitly deleted, because that seems in keeping with the action being taken.

[brmeyer]

I think UPDATE CONTENT would be more powerful if you diff'd the new derived content with the old, and made changes instead of doing a simple delete+re-create.

Definitely an intriguing idea, and one that I had thought about before.  My only concern with that is one of use cases and impact analysis.  Say, for example, you have one of the ServiceImplementation metadata artifacts pointing to a few WsdlDocument derived artifacts.  If an update changes characteristics within those derived artifacts, should that ServiceImplementation blindly continue referring to them, even if contexts have changed substantially?  How do you define "substantial enough"?  Would it be better to instead require 1.) relationship cleanup (and implicitly, "impact analysis") or 2.) a new WsdlDocument version entirely?

I'm not really arguing one way or another, but those were the initial roadblocks that came up when I started working on it.

Later, a user adds custom properties and/or classifiers to a subset of the derived artifacts.  If an update to the primary simply deletes all the derived content and regenerates it, all of that custom meta-data is lost.

That's a fantastic point.  Depending on what we decide about derived diff vs. delete, I wonder if we should also create constraints for custom properties and classifiers.  If either exist, force them to be manually removed prior to the update/delete.  If we do that, we start to better accomplish the "impact analysis" use case that we always claim.

[eric.wittmann]

Well I think overall the UPDATE CONTENT requirement is a problem with the spec.  It probably shouldn't have been allowed at all, at least when thinking about it from a WSDL or Schema perspective.  For other artifact types where derived content isn't an issue, then UPDATE CONTENT is obviously fine.

That said, I agree with you regarding the logical difficulties with maintaining the existing set of derived artifacts when possible.  I think the use-case for UPDATE CONTENT with regard to WSDL and Schema artifacts is to add non-functional things like comments.  If you make structural changes, then you are right - what does it mean to continue to refer to something that may have structurally/functionally changed?  I don't know.    I still maintain that doing the diff approach makes it more *powerful*.  But it might not be desirable...

+1 to detecting any custom meta-data change and making it a constraint violation on delete.

[brmeyer]

That said, I agree with you regarding the logical difficulties with maintaining the existing set of derived artifacts when possible.  I think the use-case for UPDATE CONTENT with regard to WSDL and Schema artifacts is to add non-functional things like comments.  If you make structural changes, then you are right - what does it mean to continue to refer to something that may have structurally/functionally changed?  I don't know.    I still maintain that doing the diff approach makes it more *powerful*.  But it might not be desirable...

Eric and I discussed this a bit more and agree that it's not really feasible.  Note that I do have a task in mind that would diff artifacts, but it will either be a holistic hash or deep comparison to see if anything changed.  Attempting to define functional vs. non-functional (ex: comments) changes would be exceedingly difficult.