[jira] [Comment Edited] (SLING-8186) Moved node is deleted if @Delete parameter points to its name
[
https://issues.apache.org/jira/browse/SLING-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738119#comment-16738119
]
Burkhard Pauli edited comment on SLING-8186 at 1/9/19 11:20 AM:
I don't see a name collision problem in the provided example. The file resource
is located at {{/content/file}} and the delete operation is against the
resource {{/content/test}}. In the provided curl command the file should be
moved from {{/content/file}} to {{/content/test/file}}. This is done with the
relative path {{./test}} against the target url
{{http://localhost:4502/content}}. Maybe the example is a bit misleading by
mixing relative and absolute path parameters - sorry for that.
Changing the order of the operation will not change the behaviour of delete
operation itself.
was (Author: bupauli):
I don't see a name collision problem in the provided example. The file resource
is located at {{/content/file}} and the delete operation is against the
resource {{/content/test}}. In the provided curl command the file should be
moved from {{/content/file}} to {{/content/test/file}}. This done with the
relative path {{./test}} against the target url
{{http://localhost:4502/content}}. Maybe the example is a bit misleading by
mixing relative and absolute path parameters - sorry for that.
Changing the order of the operation will not change the behaviour of delete
operation itself.
> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the
> request contains the @Delete parameter at the same time, the file is dropped
> and never saved to the new location.
> Step to reproduce the issue:
> # Create a node of type nt:file at the location {{/content/file}}
> # Execute the following curl command:
> {{curl -u admin:admin -F './test/title=Hello World' -F
> './test/file@MoveFrom=/content/file' -F './test@Delete=true'
> [http://localhost:4502/content]}}
> Observed behaviour:
> The file is not saved at the new location at {{/content/test/file}} and it
> is not available anymore at the old location {{/content/file}}
> Expected:
> The file is saved at the new location {{/content/test/file}} as long as
> other properties are saved when the request contains the delete operation
> (like the title property in the example above).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SLING-8186) Moved node is deleted if @Delete parameter points to its name
[
https://issues.apache.org/jira/browse/SLING-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16738071#comment-16738071
]
Burkhard Pauli edited comment on SLING-8186 at 1/9/19 10:29 AM:
[~bdelacretaz], Thank you for having a look into this issue! I think in this
edge case the question is if we can reorder the modify operations like in the
attached [^patch.diff] , so that the move and copy operation is done after the
delete. Otherwise the delete will remove the copied or moved file right after
in the same request.
Sure, this will change the old (undocumented) behaviour but I can't imagine use
cases where the old behaviour is intended because the move operation will
delete the resource anyway and the motivation to copy a resource is to keep the
source resource. Otherwise the move operation should be used. Or do I miss
something?
cc [~cziegeler]
was (Author: bupauli):
[~bdelacretaz], Thank you for having a look into this issue! I think in this
edge case the question is if we can reorder the modify operations like in the
attached [^patch.diff] , so that the move and copy operation is done after the
delete. Otherwise the delete will remove the copied or moved file right after
in the same request.
Sure, this will change the old (undocumented) behaviour but I can't imagine use
cases where the old behaviour is intended because the move operation will
delete the resource anyway and the motivation to copy a resource is to keep the
old example. Otherwise the move operation should be used. Or do I miss
something?
cc [~cziegeler]
> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
> Attachments: patch.diff
>
>
> If a file is moved to a new location with the @MoveFrom parameter and the
> request contains the @Delete parameter at the same time, the file is dropped
> and never saved to the new location.
> Step to reproduce the issue:
> # Create a node of type nt:file at the location {{/content/file}}
> # Execute the following curl command:
> {{curl -u admin:admin -F './test/title=Hello World' -F
> './test/file@MoveFrom=/content/file' -F './test@Delete=true'
> [http://localhost:4502/content]}}
> Observed behaviour:
> The file is not saved at the new location at {{/content/test/file}} and it
> is not available anymore at the old location {{/content/file}}
> Expected:
> The file is saved at the new location {{/content/test/file}} as long as
> other properties are saved when the request contains the delete operation
> (like the title property in the example above).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (SLING-8186) Moved node is deleted if @Delete parameter points to its name
[
https://issues.apache.org/jira/browse/SLING-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16735948#comment-16735948
]
Bertrand Delacretaz edited comment on SLING-8186 at 1/7/19 3:23 PM:
I have added an integration test [1] which demonstrates that the interaction
between @Delete and @MoveFrom has been like that for a long time indeed:
running that test against a Sling 8 jar with {{org.apache.sling.servlets.post}}
2.3.8 (released June 2015, way before Carsten's change mentioned above) gives
the same results.
I think we have an edge case that's not clearly documented, but I wouldn't be
comfortable removing the "delete node if property not found" behavior as that
wouldn't be backwards compatible.
We might clarify the documentation to indicate that having an @Delete parameter
pointing to the target path causes a deletion like in this example - if unsure,
users should refrain from using @Delete and @MoveFrom in the same request.
[~bupauli] what do you think?
[1]
[https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/commit/3da37cc963fa1367d07eb1ed2d37cb3296d6b270]
was (Author: bdelacretaz):
I have added an integration test [1] which demonstrates that the interaction
between @Delete and @MoveFrom has been like that for a long time indeed:
running that test against a Sling 8 jar with {{org.apache.sling.servlets.post}}
2.3.8 (released June 2015, way before Carsten's change mentioned above) gives
the same results.
I think we have an edge case that's not clearly documented, but I wouldn't be
comfortable removing the "delete node if property not found" behavior as that
wouldn't be backwards compatible.
We might clarify the documentation to indicate the having an @Delete parameter
pointing to the target path causes a deletion like in this example - if unsure,
users should refrain from using @Delete and @MoveFrom in the same request.
[~bupauli] what do you think?
[1]
[https://github.com/apache/sling-org-apache-sling-launchpad-integration-tests/commit/3da37cc963fa1367d07eb1ed2d37cb3296d6b270]
> Moved node is deleted if @Delete parameter points to its name
> -
>
> Key: SLING-8186
> URL: https://issues.apache.org/jira/browse/SLING-8186
> Project: Sling
> Issue Type: Bug
> Components: Servlets
>Affects Versions: Servlets Post 2.3.26
>Reporter: Burkhard Pauli
>Assignee: Bertrand Delacretaz
>Priority: Major
>
> If a file is moved to a new location with the @MoveFrom parameter and the
> request contains the @Delete parameter at the same time, the file is dropped
> and never saved to the new location.
> Step to reproduce the issue:
> # Create a node of type nt:file at the location {{/content/file}}
> # Execute the following curl command:
> {{curl -u admin:admin -F './test/title=Hello World' -F
> './test/file@MoveFrom=/content/file' -F './test@Delete=true'
> [http://localhost:4502/content]}}
> Observed behaviour:
> The file is not saved at the new location at {{/content/test/file}} and it
> is not available anymore at the old location {{/content/file}}
> Expected:
> The file is saved at the new location {{/content/test/file}} as long as
> other properties are saved when the request contains the delete operation
> (like the title property in the example above).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
