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

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.

Reply via email to