[
https://issues.apache.org/jira/browse/JCRVLT-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552269#comment-17552269
]
Konrad Windszus edited comment on JCRVLT-598 at 6/10/22 1:15 PM:
-----------------------------------------------------------------
New proposal: Create new IdConflictPolicy.LEGACY
Assign the newly imported conflicting node a new id in case the conflicting
existing node does not have the same parent (i.e. is no sibling). If the newly
imported node is a sibling of the existing conflicting one either remove the
existing node with the conflicting id but keep its references (in case the
conflicting one is contained in the filter) or skip the to be imported node
(and continue with importing its children as if they were below the existing
one).
I also updated the proposal in the summary. IdConflictPolicy.FAIL should stay
the default, but this default can be overwritten (e.g. for AEM) due to
JCRVLT-596 to use LEGACY instead.
was (Author: kwin):
New proposal: Create new IdConflictPolicy.LEGACY which removes existing
conflicting nodes in case they are siblings, otherwise create a new ID for the
to be imported referenceable node. I also updated the proposal in the summary.
IdConflictPolicy.FAIL should stay the default, but this default can be
overwritten (e.g. for AEM) due to JCRVLT-596 to use LEGACY instead.
> 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: Konrad Windszus
> Priority: Major
> Fix For: 3.6.2
>
> Attachments: test-duplicate-referencable-on-child-element-only.zip,
> test-referenceable.zip
>
>
> 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
> with conflicting UUIDs, both nodes were imported (and one of the UUIDs
> changed).
> Update: It turned out that this is only the conflict handling for non-sibling
> nodes, for sibling nodes the behaviour depends on whether the existing
> conflicting node is contained in the filter or not. If the newly imported
> node is a sibling of the existing conflicting it either removes the existing
> node with the conflicting id but keep its references (in case the conflicting
> one is contained in the filter) or skip the to be imported node (and continue
> with importing its children as if they were below the existing one).
> From that point of view, CREATE_NEW_ID seems to be closer (but that one
> assigns new UUIDs to *both* nodes).
> -Proposal: adjust CREATE_NEW_ID behavior to keep assigning a new UUID only
> when needed (thus preserving it for one of the nodes), and document *that*
> mode as compatible to 3.5.0.-
> Updated Proposal: Create new IdConflictPolicy.LEGACY which replicates the
> behaviour described above.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
