[
https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin....
]
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)