[
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, 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.
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, for sibling nodes the behaviour depends on whether the existing
conflicting node is contained in the filter or not. If it is contained the
to-be imported node just replaced the conflicting node, if it is not contained,
the to-be imported node is just skipped!
>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 siblings (i.e. share the same parent node), otherwise
will create a new ID for the to be imported referencable node
> 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)
