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.