[overlord-issues] [JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted

[Brett Meyer (JIRA)]

    [ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002080#comment-13002080 ] 

Brett Meyer commented on SRAMP-535:
-----------------------------------

[~eric.wittmann], is the "deleted" artifact kept purely for auditing?  If so, will reseting the UUID screw with that?  Or, are the audit nodes pulled over with the "deleted" node?

It looks like enabling same-name siblings for specific children is possible: http://www.day.com/specs/jcr/2.0/22_Same-Name_Siblings.html.  But even so, the question is the same.  How are the "deleted" artifacts used and what might the implications be?

> Reset UUID of artifact when it is deleted
> -----------------------------------------
>
>                 Key: SRAMP-535
>                 URL: https://issues.jboss.org/browse/SRAMP-535
>             Project: S-RAMP
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.5.0.Beta3
>            Reporter: Eric Wittmann
>            Assignee: Brett Meyer
>             Fix For: 0.6.0
>
>
> Currently when an artifact is deleted we do not delete the JCR node.  Instead we move it to another location in the JCR tree.  This allows us to potentially add a new node with the same UUID (e.g. a user-specified one).
> However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID.  So now if you try to delete the new artifact you'll get this:
> {code}
> A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default"
> {code}
> Possible solution is to generate a new UUID for the trashed artifact when it gets moved?  Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible).



--
This message was sent by Atlassian JIRA
(v6.3.1#6329)