[JCRVLT-598] need IdConflictPolicy compatible with 3.5.0 behavior

• Type: Sub-task
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.5.8
• Fix Version/s: 3.6.4
• Component/s: vlt
• Assignee: Konrad Windszus
• Reporter: Julian Reschke
• Created: 18/Jan/22 11:44
• Updated: 08/Jan/24 11:10
• Resolved: 10/Jun/22 13:42

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.

Issue Links

• relates to: JCRVLT-737 IdConflictPolicy.LEGACY: Parent node not found when installing a package - improve test coverage
• links to: GitHub Pull Request #225
• links to: GitHub Pull Request #244