After 12744bc81ebdaa1671a953c14ba54c637d6a9255, x2m operations are
fully batched, and deletions are processed last when the operations are
flushed, regardless of the order in which they were specified by the
write() or create() call.
This carries a risk of violating (non-deferred) unique SQL constraints,
when the operations for deleting previous lines and re-creating new
ones are processed in the same batch.
This patch executes the deletions before other operations during a
flush, which should be safer with regard to SQL constraints.
An extra constraint is added in test_performance.line to simulate this
corner case, then covered by an extra unit test.
Another unrelated test had to be altered to avoid violating the
new constraint.
This can be reproduced easily by upgrading the `project` module in master,
due to the unique constraint[1] on `ir.actions.act_window.view`, that
gets violated when processing the batch write on this o2m[2].
[1] https://github.com/odoo/odoo/blob/ccc42f16/odoo/addons/base/models/ir_actions.py#L288-L289
[2] https://github.com/odoo/odoo/blob/ccc42f16/addons/project/views/project_views.xml#L394-L396closesodoo/odoo#28314
Olivier Dony
b9ec95a8cb