I have a scenario where multiple nodes are connected to each other in a certain hierarchy. Each node has a property "isNodeActive", and the value of this property depends on the parent node's "isNodeActive" property. I need to update a node's "isNodeActive" property to either "true" or "false". When this happens, the child nodes' "isNodeActive" properties should also be updated, continuing down the hierarchy.
If a child node has multiple parents and all its parent nodes' "isNodeActive" values are "false", the child's "isNodeActive" should be updated to "false". However, if any of the parent nodes' "isNodeActive" values is "true", the child node should remain active, and the propagation should continue accordingly.
For example, in this diagram:
lets say all nodes are initialized with "isNodeActive" as true.
If I set Node3's "isNodeActive" to "false", then Node4 and Node8 should also have their "isNodeActive" set to "false", as none of their parent nodes have "isNodeActive" set to "true". Node5 should remain unaffected, and its "isNodeActive" should remain "true" because it has another parent "Node2" whose "isNodeActive" is "true". This also means that Node6 and Node7 should retain "isNodeActive = true".
If I later set Node5's "isNodeActive" to "false", then Node7's "isNodeActive" should turn "false" as it only has Node5 as a parent, and both of its parents' "isNodeActive" values are now "false". However, Node6 should remain "true", as it has another parent Node1 whose "isNodeActive" is still "true".
This is a hierarchical structure that requires traversing the subgraph originating from the root node that got updated to derive and set the new state of each descendant node.
I believe this could easily be done with a recursive algorithm using breadth first search. Cypher doesn’t have such capabilities. Cypher is also not a scripting language with the necessary flow control or state maintenance for this task.
APOC has a method that could be used to repeatedly run a statement until a condition is met. This may be applied in your case to iterate through each layer of the subgraph. One issue with this is each statement is run in its own transaction, so you not rollback already updated nodes if an exception occurred.
All that being said, this doesn’t seem to be a feasible approach. If you could implement something, you have the potential of you graph thrashing to keep it updated if you get a large volume of updates that require the child nodes to be updated. Further, you could have deadlock issues when updating.
Is it possible just to derive the active state when needed? Updating a graph in the background to maintain consistency like this is challenging.
The other option is to develop a custom procedure that updates the subgraph given the root node. The Java API would allow you to do this easily using recursion. You could create an APOC trigger to call this procedure when specific types of nodes get updated. You still have the potential of thrashing and deadlocks mentioned earlier.
