[
https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin....
]
Eric Wittmann commented on SRAMP-535:
-------------------------------------
Deleted nodes are kept for auditing, yes. The audit information lives as child nodes on
the artifact node. So changing the UUI *should* be ok. I would suggest perhaps something
like <UUID>_deleted_<timestamp> or something like that. And have
same-name-siblings enabled only for the "trash" part of the tree.
Definitely do not want to enable same-name-siblings for the main tree, as we use that
feature specifically to ensure that we don't create multiple nodes with the same UUID.
That was probably obviously but perhaps worth repeating. :)
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)