Bug
Auto commit off: uncommitted topic delete behaves differently
Issue description
During auto commit the deleting of a topic takes immediate effect: all dependent associations and topics are immediately removed. Not so when auto commit is turned off. After the deleting of the topic, dependent associations are still present.
When an adjunct is deleted and subsequently the script iterates from the coadjunct over the remaining, the deleted association to the adjunct is still present, but the player is null.
Given a topic type TT1 connected via AT1 to a topic type TT2. Instances of TT1 may take the respective role optionally and unlimted (0-*). Instances of TT1 must take the role at most once (0-1). In the case at hand an order was connected to order items. An order item was deleted and afterwards there was another iteration over all order items which yielded the deleted order item. But that should not be the case.
Workaround
Delete the specific association for now, not the topic. Then everything works as expected.
Developer comments
The deletion of a dependent items must take effect on the in-memory dobjects immediately.
The main issue or challenge that comes with auto commit off, is that every event happens twice, one time in MEMORY layer and one time in the DB layer. In a long import, there might be minutes or hours between the two. With auto commit on, the API call is applied to MySQL first, then the dobjects are modified. The time difference between the events is minimal in the milisecond range.
Another problem is that when a BEFORE DELETE trigger executed at MySQL write time, the dobject layer will no longer have the information, because it was deleted. But actually the more pressing problem is that dobject representation is errenous after a delete because topics and asscociations that should no longer exist, are still present. Zombies. When the triggers should run is another question.
This is resolved. The dependent associations and topics are removed immediately from the dobject space. The depedencies are currently computed twice, once at the call time and when the package is written to the db.
|
Work sessions4
Start |
2023-04-12T08:11:06
|
End |
2023-04-12T09:56:28
|
Participant |
Robert Cerny
|
Start |
2023-04-27T10:12:50
|
End |
2023-04-27T11:12:23
|
Participant |
Robert Cerny
|
Start |
2023-05-12T08:52:23
|
End |
2023-05-12T11:00:00
|
Participant |
Robert Cerny
|
Start |
2023-05-12T13:14:25
|
End |
2023-05-12T14:22:42
|
Participant |
Robert Cerny
|
|
We are sorry
This page cannot be displayed in your browser. Use Firefox, Opera, Safari, or Chrome instead.