#25 Child watches are not triggered when the node is deleted

3.0.0
closed
Benjamin Reed
None
5
2008-06-10
2008-06-01
Benjamin Reed
No

If a client sets a watch on "/foo" with a getChildren("/foo" ...) and "/foo" gets deleted, no watch event is triggered. (Ever.)

It could be argued that this is correct behavior since the children did not change, but it can lead to confusion since "/foo" could be recreated and children added and still the watch would not get triggered. (We trace watches by znode instance and deleting and creating "/foo" causes a new znode instance.)

The correct behavior should be that when a znode is removed there are three events triggered: parent child watches, znode data watches, and znode child watches.

Discussion

  • Benjamin Reed
    Benjamin Reed
    2008-06-01

    • milestone: --> 3.0.0
     
  • Patrick Hunt
    Patrick Hunt
    2008-06-03

    Logged In: YES
    user_id=12853
    Originator: NO

    This is going to be a bit more complicated that it seems. Let me know what you think of the following:

    The server has 2 watcher lists; data & child. Currently watchers are triggered exclusively to one or the other list (all datachanged are on data list, all children changed on child list,etc...)

    Merely adding a "childwatches.trigger(path, nodedeleted)" to datatree will result in (potentially) two nodedeleted events being sent to a watcher (if client did a exists(path) & getchildren(path) for example). I don't believe we want to do this.

    There are two options afaict; add a new watch list "deletedNodeWatches" to datatree that contains both data & child watches to be triggered for nodedelete events only, or continue to have 2 lists and filter out any duplicate events during the trigger phase.

    Adding more lists doesn't seem like a great option. Option 2 would require a change to watchmanager.triggerwatches to return the set of watchers triggered, which would be used to filter out duplicate triggers.

    pseudo for datatree.deletenode:
    processedwatches = datawatches.triggerwatches(path, nodedeleted)
    childwatches.triggerwatches(path, nodedeleted, processedwatches)

    triggerwatches would be updated to use processwatches parameter to filter out duplicate nodedeleted events from being generated (the child watch would be cleared on the server)

    Secondly the client (current patch) also has two lists - data and child watches. The client will have to use the same trick -- trigger both data and child watches, eliminate duplicates by uniquely triggering based on path/watcher pairs. (process the data watches, process the child watches filtering out any dups from being generated).

     
  • Patrick Hunt
    Patrick Hunt
    2008-06-03

    • assigned_to: nobody --> breed
     
  • Benjamin Reed
    Benjamin Reed
    2008-06-03

    Logged In: YES
    user_id=154690
    Originator: YES

    I don't think we want another list, that will just make things more complicated.

    Option 2 is best since triggerWatch already builds a HashSet that we can simply return.

     
  • Patrick Hunt
    Patrick Hunt
    2008-06-10

    • status: open --> closed