You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Julian Reschke (Jira)" <ji...@apache.org> on 2023/02/14 11:50:00 UTC
[jira] [Updated] (JCRVLT-685) ImportMode REPLACE vs IdConflictPolicy LEGACY vs stashing
[ https://issues.apache.org/jira/browse/JCRVLT-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated JCRVLT-685:
----------------------------------
Description:
Consider this case:
- existing node "/tmp/x" in repo with UUID x1 and mixin type xm that requires a child node "/tmp/x/child"
- package import with IdConflictPolicy.LEGACY and ImportMode REPLACE (default). Package contains /tmp/x" with UUID x2 (!= x1) and does not have the mixin type xm, nor the child node required by it
Import detects UUID present in package and on node to be updated, decides to stash it. New node is created, child nodes are moved back from stashed node, but properties are not (due to ImportMode REPLACE), thus the mixin type is not re-added. Import fails.
Either we should restore the mixin type, or we should not restore the child that is only allowed by that mixin type.
(This is a change in behavior introduced by JCRVLT-551)
was:
Consider this case:
- existing node "/tmp/x" in repo with UUID x1 and mixin type xm that requires a child node "/tmp/x/child"
- package import with IdConflictPolicy.LEGACY and ImportMode REPLACE (default). Packacge contains /tmp/x" with UUID x2 (!= x1) and does not have the mixin type xm, nor the child node required by it
Import detects UUID present in package and on node to be updated, decided to stash it. New node is created, child nodes are moved back from stashed node, but properties are not (due to ImportMode REPLACE), thus the mixin type is not re-added. Import fails.
Either we should restore the mixin type, or we should not restore the child that is only allowed by that mixin type.
(This is a change in behavior introduced by JCRVLT-551)
> ImportMode REPLACE vs IdConflictPolicy LEGACY vs stashing
> ---------------------------------------------------------
>
> Key: JCRVLT-685
> URL: https://issues.apache.org/jira/browse/JCRVLT-685
> Project: Jackrabbit FileVault
> Issue Type: Bug
> Components: vlt
> Affects Versions: 3.5.4
> Reporter: Julian Reschke
> Priority: Major
>
> Consider this case:
> - existing node "/tmp/x" in repo with UUID x1 and mixin type xm that requires a child node "/tmp/x/child"
> - package import with IdConflictPolicy.LEGACY and ImportMode REPLACE (default). Package contains /tmp/x" with UUID x2 (!= x1) and does not have the mixin type xm, nor the child node required by it
> Import detects UUID present in package and on node to be updated, decides to stash it. New node is created, child nodes are moved back from stashed node, but properties are not (due to ImportMode REPLACE), thus the mixin type is not re-added. Import fails.
> Either we should restore the mixin type, or we should not restore the child that is only allowed by that mixin type.
> (This is a change in behavior introduced by JCRVLT-551)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)