Change
Tobject commit and database commit
Issue description
At the core of this issue lies the relationship between a tobject commit and the database commit. Currently this is a bit in the dark and there might be some significant problems lurking beneath somewhere. This issue should formalize their releationship and confirm it by tests.
Developer comments
Currently a tobject commit does not imply a db commit. A tobject commit applies collected changes made in memory to the database and updates the dobjects. A db commit is just an ordinary MySQL commit after a transaction has been started. Given a series of DB trx only the first one can be commited in Topincs, so that you can freely start a transaction without having to worry too much. A service call starts a DB transaction TRX1. Within this service call series of tobject commits TC1, TC2, … can be performed. If an expection occurs after TC1, the changes of TC1 are currently rolled back because TRX1 is rolled back. What happens to the dobjects in this case?
A tobject commit creates a package which is persisted with minimal db statements. An initial (or root) commit TC1 can cause several child commits TC1-2, TC1-3, … TC1-n through triggers. How many DB trx should this cause: 1 or n? If it is n and not only 1: How do you repeat the work of the triggers in case there is an error in a late trigger.
The treatment of nested service calls is another question. They are currently not causing a tobject commit. So if an import is distributed over 5 sub imports, per distinct source table, there is only one commit. What happens if the user calls an explicit commit in one of the sub imports: the tobject commit is performed, but not the db commit.
It would be a big surprise to the developer, if he codes an explict commit and learns later that the data has been rolled back due to an error within the same process, but after the commit.
Ideally there would never be the need for an explicit commit from the administrator. But it is an advantage of explicit commits that you can split up large import into smaller chunks.
A package P1, which causes packages P2, P3, … Pn through triggers, forms one transaction. Either P1-n go through, or nothing.
Implemented requested tests.
|
Work sessions3
Start |
2023-06-06T13:00:42
|
End |
2023-06-06T15:00:50
|
Participant |
Robert Cerny
|
Start |
2023-06-25T08:00:00
|
End |
2023-06-25T10:27:38
|
Participant |
Robert Cerny
|
Start |
2023-06-25T11:00:00
|
End |
2023-06-25T11:53:22
|
Participant |
Robert Cerny
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.