[
https://issues.apache.org/jira/browse/JCRVLT-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated JCRVLT-598:
-----------------------------------
Description:
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, sibling nodes behave like FORCE_REMOVE_CONFLICTING_ID
>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 removes conflicting
nodes in case they are not siblings, otherwise will create a new ID for the to
be imported referencable node
was:
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, sibling nodes behave like
>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.
> 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
> 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, sibling nodes behave like FORCE_REMOVE_CONFLICTING_ID
> 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 removes
> conflicting nodes in case they are not siblings, otherwise will create a new
> ID for the to be imported referencable node
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
