[ 
https://issues.apache.org/jira/browse/SLING-10136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17394739#comment-17394739
 ] 

Bertrand Delacretaz commented on SLING-10136:
---------------------------------------------

Considering that there is a "create path" operation, I think there should also 
be a "delete path".

However that's quite a dangerous operation, and might take a long time if 
there's lots of content and/or listeners triggered during deletion.

Do people have an idea on how to avoid the risk, or make sure whoever writes 
that statement is aware of the risk?

One approach might be to count the child nodes of the deletion candidate 
recursively and failing the command once that count reaches a set limit. And 
maybe allow raising the limit value with {{DELETE PATH /somepath LIMIT <N>}} 
where N sets a new limit.

That's a crude mechanism but would at least make people aware that in general 
this is meant to delete small quantities of content only.

Alternatively, we might create a version of the path before deleting it, to 
provide a way to restore it if needed, but I'm not sure if that's practical or 
if that might cause other problems.

> Sling Repo Init: Add option to delete paths
> -------------------------------------------
>
>                 Key: SLING-10136
>                 URL: https://issues.apache.org/jira/browse/SLING-10136
>             Project: Sling
>          Issue Type: New Feature
>          Components: Repoinit
>    Affects Versions: Repoinit Parser 1.6.4, Repoinit JCR 1.1.30
>            Reporter: Henry Kuijpers
>            Priority: Major
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Given that we are able to create paths, it would also be beneficial to be 
> able to delete paths as well. 
> In our case, we're migrating a legacy setup to Sling Repo Init, where there 
> are some "leftover" nodes in the instances. Given that Sling Repo Init is an 
> "admin" way to initialize a repo, it would be very nice if delete statements 
> could be supported.
> In our case, we would want to delete /apps/foundation, for example, because 
> historically there seem to have been modifications made there.
> This mandates for a simple syntax like "delete path /apps/foundation" being 
> supported.
> Another case is that we would like to cleanup /apps/cq, however, there are 
> some nodes that are maintained by the product (in our case AEM), such as 
> /apps/cq/xssprotection and also /apps/cq/core/content/nav/tools. 
> This mandates for a slightly more complicated syntax such as "delete path 
> /apps/cq (!/xssprotection,!/core/content/nav/tools,*)", however, I would be 
> fine with multiple delete path statements as well, for that usecase.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to