[
https://issues.apache.org/jira/browse/JCRVLT-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479150#comment-17479150
]
Konrad Windszus commented on JCRVLT-598:
----------------------------------------
I think we need to check these two cases
a) UUID conflict between imported node (from package) and existing node in repo
(outside package)
b) UUID conflict between imported node (from package) and another imported node
(from package)
I just considered a) when implementing JCRVLT-551. So once we adjusted the
behaviour of CREATE_NEW_ID we should update both javadoc of IdConflictPolicy
and https://jackrabbit.apache.org/filevault/referenceablenodes.html to outline
the behaviour for both a) and b).
> need IdConflictPolicy compatible with 3.5.0 behavior
> ----------------------------------------------------
>
> Key: JCRVLT-598
> URL: https://issues.apache.org/jira/browse/JCRVLT-598
> Project: Jackrabbit FileVault
> Issue Type: Sub-task
> Components: vlt
> Affects Versions: 3.5.8
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Major
>
> Currently, according to the documentation
> (https://jackrabbit.apache.org/filevault/referenceablenodes.html),
> "IdConflictPolicy.FORCE_REMOVE_CONFLICTING_ID" is supposed to behave as 3.5.0
> did.
> My tests show however that in 3.5.0, when importing a package with two nodes
> ith conflicting UUIDs, both nodes were imported (and one of the UUIDs
> changed).
> From that point of view, CREATE_NEW_ID seems to be closer (but that one
> assigns new UUIDs two *both* nodes).
> Proposal: adjust CREATE_NEW_ID behavior to keep assign a new UUID only when
> needed (thus preserving it for one of the nodes), and document *that* mode as
> compatible to 3.5.0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
