proposal: a master's delete and the composition children it owns

[delchev]

composition: true declares ownership - the child is a detail of its master with a NOT NULL key because it cannot exist without it - and nothing in the model says what a delete of the master does to those children. The observed answer is: nothing. The rows stay, pointing at a key that no longer exists, and while no surface renders them (a detail is reached through its master's page) every report, roll-up and aggregate over the child keeps counting them:

DELETE VacationRequest 2   -> accepted
GET    VacationDay ?Request=2   -> the five rows are still there
GET    VacationEntitlement 1    -> consumed 2 / balance 0 / EXHAUSTED

Proposal 0033: whenMasterDeleted: cascade | refuse on the composition relation, default cascade. cascade deletes each child as a deletion in full - its own children with it, its deletion observed by the reactions bound to it, all of it one atomic unit with the master's own. refuse rejects the master's delete while any child exists, naming both entities.

The behaviour is not conditional on the key: cascade is what a conforming generator does for every composition, authored or not, because it is what composition means. The key exists to choose refuse - and neither outcome may be limited to deletes arriving over a public interface, since a reaction or a further cascade reaches the same rows.

Implementation: eclipse-dirigible/dirigible#7111 (issue eclipse-dirigible/dirigible#7100).