KILL of an M node should invoke any database triggers defined at deeper levels of that M node
Final Release Note
Description
YottaDB currently does not invoke triggers for sub-trees under a KILL
operation. Below is relevant text from the documentation at https://docs.yottadb.com/ProgrammersGuide/triggers.html#trigger-invocation-and-execution-semantics
YottaDB does not check nodes in sub-trees to see whether they have matching triggers.
But that poses a problem with the KILL
command. A KILL
command on an M node deletes not just that node but the entire sub-tree of M nodes under that node. It is possible that one or more KILL
or ZKILL
type of database triggers are defined for the M nodes under the sub-tree being killed. In that case, currently the top level KILL
command will not invoke the deeper level database triggers.
This is how YottaDB (and the upstream GT.M) database triggers have behaved from day one.
But this has been seen to pose an issue for Octo where the cross reference it builds gets out of sync with the application data if the application does a top level KILL. See discussion at YottaDB/DBMS/YDBOcto#630 (comment 454320092) for details.
Draft Release Note
KILL of an M node now invokes any KILL/ZKILL type of database triggers defined at deeper levels of the M node being killed. For example, if different KILL
type triggers are defined for the M nodes ^GBL(level1)
, ^GBL(level1,level2)
and ^GBL(level1,level2,level3)
, a KILL ^GBL(level1)
will invoke the KILL
triggers for ^GBL(level1)
, ^GBL(level1,level2)
and for ^GBL(level1,level2,level3)
as part of the KILL
command. Previously, it would only invoke the KILL
trigger for ^GBL(level1)
which could cause application level issues due to skipping the trigger invocation for the deeper levels.