Thoughts on deleting a row from a reference set

1
Consider the following situation: Domain model with two entities: Invoice and Specification Entity Invoice has a Reference Set defined which points to entity Specification Entity Invoice has a BeforeCommit event that performs checks on records in the reference set. I created a form based on Invoice and included a reference set selector based on Specification. Next, I implemented two microflow buttons: "Add row" and "Delete Row". What I have noticed is that when an object is deleted from Specification (and thus from the reference set of the Invoice object that the Specifcation object belongs to) that the BeforeCommit event of the Invoice object is not triggered. To get around this issue (if it is an issue, more on that thought later) I created a BeforeDelete event for entity Specification that explicity updates the reference set of the master Invoice object, removing the reference to the Specification object that will be deleted, thus triggering the BeforeCommit event of the Invoice object. In my opinion, this is a bit weird. Deleting a Specification object has consequences for the Invoice object in my opinion; the reference set is a property of the Invoice object, which was changed by the Delete Object action for the Specification object. Therefore I expect that the BeforeCommit event of the Invoice object should be triggered as well, without the need of writing addtional BeforeCommit event handlers on the Specification object. I would love to hear any thoughts/remarks from one of the Mendix developers on this subject. Am I wrong here or has it been setup deliberately like this to prevent all kinds of chain reactions of event handlers kicking in?
asked
1 answers
0

To be honest i have to disagree here. Committing one object is something different from changing it.

In your example you delete the specification which results in a change of your invoice. But it does not result in a commit of your invoice. Thus It would be inconsistent to trigger this event.

I agree with you that deleting the specification object has consequences for the invoice object, but i disagree with the assumption that all checks that influence the invoice should be done on the invoice itself.

answered