You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Konrad Windszus (Jira)" <ji...@apache.org> on 2022/06/09 11:36:00 UTC

[jira] [Commented] (JCRVLT-598) need IdConflictPolicy compatible with 3.5.0 behavior

    [ https://issues.apache.org/jira/browse/JCRVLT-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552142#comment-17552142 ] 

Konrad Windszus commented on JCRVLT-598:
----------------------------------------

With FileVault 3.2.8 (still shipped with AEM 6.5) I get the following behaviour for the package at https://github.com/apache/jackrabbit-filevault/tree/master/vault-core/src/test/resources/test-packages/referenceable-dup.zip:

{code}
Importing content... 
- /
A /tmp
A /tmp/duplicate
A /tmp/duplicate/child
R /tmp/referenceable
- /tmp/referenceable/child
saving approx 4 nodes... 
Package imported. 
{code}

So in fact, it removes the conflicting node. The same behaviour can be observed with latest SNAPSHOT and default conflict policy: {{IdConflictPolicy.FORCE_REMOVE_CONFLICTING_ID}}, so currently I am failing to see any difference between FileVault 3.2.8 and 3.6.0 for that particular package.

> 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
>
> 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).
> 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.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)