[
https://issues.apache.org/jira/browse/ZOOKEEPER-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850385#action_12850385
]
Patrick Hunt commented on ZOOKEEPER-729:
----------------------------------------
bq. Would it be ok if we have a separate jira to track it.
sure. link it to this one.
bq. that was an inspiration from hdfs
that's fine, I was just thinking to keep down the proliferation of cmds...
(personally I would have modeled all the commands on unix fs commands...)
bq. not sure what effect async will have
In ZK all operations are ordered. So if a single client session calls async
delete(/foo/a/b) then async delete(/foo/a), then async delete(/foo) it will be
deleted in that same order, guaranteed. You will get callbacks with
success/fail of each operation, so you
would need to wait for those to be sure. sync is fine, just saying async is
faster which might be important if the tree is large...
bq. You should get rid of the System.out.println lines
I think we want to use system out for user interaction, LOG is for debugging
(at least that's what we're doing in that class today.)
Typically in unix you don't message to the console for expected
ph...@valhalla:~$ touch foo
ph...@valhalla:~$ rm foo
ph...@valhalla:~$
just for error conditions. I'd put those printlns for delete into the LOG
(success/debug information) and println only if the
user's operation failed to do what was expected.
> zkCli.sh -rmr /node
> -------------------
>
> Key: ZOOKEEPER-729
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-729
> Project: Zookeeper
> Issue Type: New Feature
> Components: c client, java client
> Reporter: Kay Kay
> Assignee: Kay Kay
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-729.patch
>
>
> Recursively delete a given znode in zookeeper, from the command-line.
> New operation "rmr" added to zkclient.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
