On 21/07/2017 19:00, Simon Slavin wrote:

I’m minded to leave things as they are, with the order undefined.  If you 
really want to trigger a number of different operations in a specific order, 
put those operations all in one trigger, one after another.

Yes, possible now with the reminder of Peter: inserts can be conditional as well.

Alternatively, instead of having
...
have

Operation A
Trigger A1 on operation A performs operation B
Trigger B1 on operation B performs operation C
Trigger A3 on operation A performs operation D

That way you’ll know that you’ll get either ABCD or ABDC, but either way C will 
be executed after B.

Right, but not applicable in my special case: B is a global timestamp server that delivers unique timestamp Id's that are further used by several operations (e.g., closing the current state then creating a new current state). So trigger B1 does not know which operation will be performed next. Only triggers of type A1 know.

I have a question.  Would you expect to see depth-first or width-first 
recursion, and why ?

I suppose you refer to the order cascading triggers must be fired, as in the architecture mentioned above. Am I right? Quite difficult question, to which I have no general answer (probably, there is none). In MY case (automatic management of transaction time temporal DB), I would say that a depth-first execution would be the most natural. If action A triggers actions B1 and B2, and action B1 triggers actions C11 and C12, I think that the final state of the data should be easier to understand if it results from sequence A.B1.C11.C12.B2, even if B2 modifies the result of A.B1.C11.C12. I can imagine that the result of A.B1.B2.C11.C12 could lead, in some cases, to unexpected final states. It seems that depth-first order is applied by Oracle (I don't know for others), though the protocol is fairly complicated by their "mutating table" concept, which often leads to convoluted programming. The documentation is unclear but it seems to suggest that the "follows/precedes" clauses apply to select the next sibling trigger after the child triggers have completed. But I may be wrong!

Thanks for the suggestions and discussion

JL

_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to