We are looking for a way to do extra db operations as part of the create/update/delete item transaction, so we could implement a outbox pattern for a kafka producer, doing additional writes in a outbox table. The idea is that we should only persist the changes to this outbox table if the create/update/delete item operation was successful, hence it needs to be part of the same transaction.
Checking the source code, it seems for update the filter hook happens before the transaction, but for create, the filter happens inside the transaction, is my understanding correct? (and if yes, shouldn’t they have the same behavior?)
There has been a github issue about this recently.
If I understood @brainslug correctly, the filter hooks gets the transaction passed only when doing relational updates.
No idea tho, where and how this is done.
Edit: And I’m also curious why it’s done this way (performance? deadlocking?)
The idea is that we should only persist the changes to this outbox table if the create/update/delete item operation was successful, hence it needs to be part of the same transaction.
For that usecase it may make more sense to use an action hook instead since these are fired after the database operation has sucessfully completed.
Brainslug, the problem is that we need it to be transactional: if the create/update/delete operation succeeds, we also write to the outbox table, otherwise nothing is written.
If I use action , there is the risk of the Item changes being persisted on db, but the writing to the outbox table failing (like if the instance is suddenly terminated). It would be enough if we could do it with filter, but we found this “inconsistency” where on update the filter isn’t part of the transaction, but for create it is:
Checking the source code, it seems for update the filter hook happens before the transaction, but for create, the filter happens inside the transaction, is my understanding correct? (and if yes, shouldn’t they have the same behavior?)