does children's data is always guarantee included in the watcher event ?

[Zhang Xiaoyu <zh...@gmail.com>]

Hi, guys,
I am trying to use PathChildrenCache to set up a watcher on a ZK path, so
when any children is added to the path, I will get a watcher event.

My client logic is in the watcher event, do getData().getData() to get the
children's data. This is working for me. The question is can I always relay
on this or should I have a backup option if data is a empty byte[], I still
retrieval data based on child's path ?

My logic in watcher event is:

if (data.length != 0) {
    //do the following logic
} else {
    byte[] data = client.getData().forPatch(childPath);
    // do the following logic
}

do I need the else block ? Let me know if need more code explanation.

Thanks,
Johnny

Re: does children's data is always guarantee included in the watcher event ?

[Cameron McKenzie <mc...@gmail.com>]

For CHILD_ADDED and CHILD_UPDATED events you will always get the data for
the node, but there's no guarantee that the node is actually going to have
data. If some other application (or person) created a zNode under the
cache's path without data this would potentially break your application, so
it's probably best to go on the defensive side and handle both cases.
cheers

On Wed, Jun 10, 2015 at 10:36 AM, Zhang Xiaoyu <zh...@gmail.com>
wrote:

> Hi, guys,
> I am trying to use PathChildrenCache to set up a watcher on a ZK path, so
> when any children is added to the path, I will get a watcher event.
>
> My client logic is in the watcher event, do getData().getData() to get the
> children's data. This is working for me. The question is can I always relay
> on this or should I have a backup option if data is a empty byte[], I still
> retrieval data based on child's path ?
>
> My logic in watcher event is:
>
> if (data.length != 0) {
>     //do the following logic
> } else {
>     byte[] data = client.getData().forPatch(childPath);
>     // do the following logic
> }
>
> do I need the else block ? Let me know if need more code explanation.
>
> Thanks,
> Johnny
>