Closed victorperez2911 closed 6 years ago
Hi Victor,
Are you referring to the effect of having a trigger handler make some other changes on that same context? Assuming that is what you mean, the trigger events are fired like a "queue of queues".
Triggers which are responding to the initial changes made in its context are fired in order, start to finish. Any changes made to the context (ones which have a trigger) in those trigger handlers are executed next, in order, from start to finish. That process continues until there are no triggers left to fire. It is worth noting that you can easily create a situation of endless recursive triggers (for example, if your Inserting
trigger on MyEntity
adds another MyEntity
to the same context).
Let me know if I've misunderstood your question. I'd like to help.
Cheers, Nick
Hi Nick.
I'm going to ask a slightly more direct question, using an example to see if we're talking about the same thing.
if I put a handler on the "inserted" trigger of an Entity, and in the scope code of that handler an exception is thrown, will the inserted data remain in the Database?
Ah ok. Good question. Yes, it will remain in the database. "Inserted" trigger is specifically for handling a situation once you know the data is persisted.
Ok @NickStrupat .
Tks.
Hello
In the documentation I did not see anything that explains how the library works with the atomicity between the commands that originated the activation of the trigger to the commands executed in the trigger itself.
Is there any native library mechanism?
If not, any tips on how to work on this subject?
Victor Perez