[
https://issues.apache.org/jira/browse/JCRVLT-598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552220#comment-17552220
]
Konrad Windszus edited comment on JCRVLT-598 at 6/9/22 3:00 PM:
----------------------------------------------------------------
With a slightly different test package I can reproduce the issue:
[^test-duplicate-referencable-on-child-element-only.zip]
1. Both nodes kept (one with newly assigned id) pre 3.5.2
2. One node removed since 3.5.2
For case 1. the following is logged
{code}
09.06.2022 15:34:12.632 *WARN* [qtp1887947872-52909]
org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
/tmp/referenceable/child is referenceable and collides with existing node at
/tmp/duplicate/child. Will create new UUID.
{code}
This comes from
https://github.com/apache/jackrabbit-filevault/blob/c612dda36895d379ec57f6d2834158ea513f2967/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L826
This is an inconsistency in FileVault pre 3.5.2 which has different behaviour
of conflict resolving depending on whether the duplicate affects a sibling node
(i.e. both share the same parent) or not:
https://github.com/apache/jackrabbit-filevault/blob/c612dda36895d379ec57f6d2834158ea513f2967/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L825
[~tripod] Any idea why you implemented it like this?
was (Author: kwin):
With a slightly different test package I can reproduce the issue:
[^test-duplicate-referencable-on-child-element-only.zip]
1. Both nodes kept (one with newly assigned id) pre 3.5.2
2. One node removed since 3.5.2
For case 1. the following is logged
{code}
09.06.2022 15:34:12.632 *WARN* [qtp1887947872-52909]
org.apache.jackrabbit.vault.fs.impl.io.DocViewSAXImporter Packaged node at
/tmp/referenceable/child is referenceable and collides with existing node at
/tmp/duplicate/child. Will create new UUID.
{code}
This comes from
https://github.com/apache/jackrabbit-filevault/blob/c612dda36895d379ec57f6d2834158ea513f2967/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L826
This is an inconsistency in FileVault pre 3.5.2 which has different behaviour
of conflict resolving depending on whether the duplicate affects a sibling node
(i.e. both share the same parent) or not:
https://github.com/apache/jackrabbit-filevault/blob/c612dda36895d379ec57f6d2834158ea513f2967/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/impl/io/DocViewSAXImporter.java#L825
> 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).
> 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)
