[
https://issues.apache.org/jira/browse/SLING-10463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17359308#comment-17359308
]
Angela Schreiber edited comment on SLING-10463 at 6/8/21, 12:14 PM:
--------------------------------------------------------------------
[~bdelacretaz], since i was involved with the investigation of the issue that
lead to this report by [[email protected]]: the problem surfaced because
_'create path /node1/node2-but-there-is-a-property_ succeeded but the
subsequent _'set property on /node1/node2-but-there-is-a-property'_ failed with
{{PathNotFoundException}}. So having repo-init fail early would have helped a
lot.
The patch [[email protected]] would have gracefully avoided any failure
during repo-init (as long as the repository supports
OPTION_NODE_AND_PROPERTY_WITH_SAME_NAME_SUPPORTED) but I suspect that it had
caused regressions later on..... while from a JCR point of view the patch is ok
and same-name-node-and-property is legal, my feeling is that there exists
plenty of JCR-1.0 code that doesn't use the 2.0 methods {{Session.nodeExist}},
{{Session.propertyExists}}, {{Session.getNode}} and {{Session.getProperty}}
instead of the corresponding general-item variants. So, the conservative
approach would be a safe bet. also in Sling-based application
same-name-node-and-property looks pretty awkward, doesn't it? and i would not
be surprised if it caused other sling features to break.
was (Author: anchela):
[~bdelacretaz], since i was involved with the investigation of the issue that
lead to this report by [[email protected]]: the problem surfaced because
_'create path /node1/node2-but-there-is-a-property_ succeeded but the
subsequent _'set property on /node1/node2-but-there-is-a-property'_ failed with
{{PathNotFoundException}}. So having repo-init fail early would have helped a
lot.
The patch [[email protected]] would have gracefully avoided any failure
during repo-init (as long as the repository supports
OPTION_NODE_AND_PROPERTY_WITH_SAME_NAME_SUPPORTED) but I suspect that it had
caused regressions later on..... while from a JCR point of view the patch is ok
and same-name-node-and-property is legal, my feeling is that there exists
plenty of JCR-1.0 code that doesn't use the 2.0 methods {{Session.nodeExist}},
{{Session.propertyExists}}, {{Session.getNode}} and {{Session.getProperty}}
instead of the corresponding general-item variants. So, the conservative
approach would be a safe bet. also in Sling-based application
same-name-node-and-property looks pretty awkward, doesn't it? and i would be
surprised if it caused other sling features to break.
> Repoinit fails to create node if property already exists at the same path
> -------------------------------------------------------------------------
>
> Key: SLING-10463
> URL: https://issues.apache.org/jira/browse/SLING-10463
> Project: Sling
> Issue Type: Bug
> Components: Repoinit
> Reporter: Tom Blackford
> Priority: Minor
> Attachments: SLING-10463.patch
>
>
> If a property already exists at the path of a node described in repoinit,
> then the repoinit will incorrectly assume the node does not need to be
> created.
> Test case & fix - [^SLING-10463.patch]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
