[ 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.