Issue description
Topics that are created in an AFTER-SAVE-NEW topic trigger are not present when the service is run with auto commit off.
Developer comments
This is tricky. I assume the cause is a subtle change in behavior introduced to the switch to [11523, package writing in POST requests] for speed and in order to achieve a complete change log of the store. Given two new names N1 and N2 that enter through the Tobject API in a POST service. With autocommit on they are fired immediately before the set call ends. With auto commit off they are only fired at the next commit. Most likely what happend in the case at hand is this: the trigger did fire at the very end of the POST request, but since auto commit was still on, a no more commit calls were performed, the temporary topic map in memory was never commited to the store.
The question therefore is whether the trigger should fire at the same time as it does with auto commit on. Or whether there should be an additional commit at the end. In some cases the triggers need the final id of the topics, e.g. when an email is sent out upon topic creation, but this only affects AFTER-SAVE-NEW-topic.
In 99% of the cases triggers augment or modify the topic map additionally through the Tobject API. But the issue with the ids remains. During the execution of the trigger, the new uncommited topics will only have a temporary id, a negative integer. There is a few scenarios where this will lead to errors:
* The trigger creates a document which contains the id.
* The trigger sends an email which contains the id.
* The trigger calls or schedules a call to a service with the topic as an argument. Call does make sense as the service call will be performed in the same PHP process. Initially i thought call does not make sense.
* The trigger creates a note.
This would all go away, if the trigger execution is soley happening when the package is written to Mysql. Just like when it comes from the client.
Maybe a generic execution buffer would do the trick. At least for email and note. pdf and call require a return value, so that won't work.
I think it is best if the trigger is executed at DB write and not MEMORY write. This does not only resolve the temporary id problem, but also other possible issue, e.g. notes are created with the tobject API, so during trigger execution new topics are created. Thus you have a change package A and a change package B. Should A be rolled back when something fails in B. The essential question is, whether trigger changes should be considered part of the original changes or not. If not there is the need for an implicit commit.
This only affects item triggers. Not form triggers, since their position in the process is independent of autocommit.
I think it should be no different from when the topic map would have been submitted by the form: the triggers run at db insert time.
When autocommit is off, changes are made in memory, then the commit creates a package P1. Triggers are processed within this package and can result in a new package P2, a trigger package. P2 can again produce trigger package P3. Probably there is no need to limit this nesting, but put a hard high limit in, just in case. By default a service will be commited in the future after the computational component has been processed, in most cases, at the end of service execution – the output for a POST service is often very simple. In case of nested calls, the commit only happens on the top level. If the administrator really needs the result of trigger within the computational component, he needs to call commit explicitly. This should do it.
The nesting limit for triggers is 10, since there is not a single use case in production where a trigger causes another trigger. So currently 2 would suffice.
|
Work sessions10
Start |
2023-01-10T07:43:42
|
End |
2023-01-10T09:44:38
|
Participant |
Robert Cerny
|
Start |
2023-01-16T09:00:00
|
End |
2023-01-16T11:15:13
|
Participant |
Robert Cerny
|
Start |
2023-01-23T10:37:04
|
End |
2023-01-23T11:31:09
|
Participant |
Robert Cerny
|
Start |
2023-01-24T07:27:19
|
End |
2023-01-24T12:06:59
|
Participant |
Robert Cerny
|
Start |
2023-01-24T14:09:34
|
End |
2023-01-24T16:33:04
|
Participant |
Robert Cerny
|
Start |
2023-01-24T18:33:04
|
End |
2023-01-24T20:05:07
|
Participant |
Robert Cerny
|
Start |
2023-01-25T16:24:48
|
End |
2023-01-25T17:19:11
|
Participant |
Robert Cerny
|
Start |
2023-01-25T18:44:27
|
End |
2023-01-25T19:49:31
|
Participant |
Robert Cerny
|
Start |
2023-01-26T08:02:27
|
End |
2023-01-26T10:52:41
|
Participant |
Robert Cerny
|
Start |
2023-01-26T14:00:00
|
End |
2023-01-26T16:28:49
|
Participant |
Robert Cerny
|
|