You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Angela Schreiber (Jira)" <ji...@apache.org> on 2021/06/08 12:15:00 UTC
[jira] [Comment Edited] (SLING-10463) Repoinit fails to create node
if property already exists at the same path
[ 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 [~rma61870@adobe.com]: 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 [~rma61870@adobe.com] 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 [~rma61870@adobe.com]: 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 [~rma61870@adobe.com] 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)