A typical scenario is adding entities to the commitcontext for deletion / insertion using setRemoveInstances and setCommitInstances methods of commitcontext in
getDsContext().addBeforeCommitListener.
Sometimes the order of execution is important, especially when you want to first delete and after to insert the new row to avoid constraint violation errors. Now the workaround is to this in the middleware using Entitymanager and define 2 transactions: for delete and insert.
I saw the milestone for 6.7 (https://youtrack.cuba-platform.com/issue/PL-9438) and I thought about it.
Hi,
Sometimes the order of execution is important, especially when you want to first delete and after to insert the new row to avoid constraint violation errors
This does not make sense since we use Eclipse Link JPA implementation. In fact, JPA providers do not send SQL statements to a DB immediately, but do it only on flush / transaction commit. They do know better what order to use fix transaction state to a DB.
The issue you mentioned is aimed to fix the problems with the error reporting. If we have an error with constraint on DB after transaction commit it will be raised anyway, but if we have 2 errors with different instances in CommitContext we want to have deterministic order of this errors.