william-andre
c45998c836
Change the way the uniqueness of the sequence numbers is ensured. Instead of using a `SELECT FOR UPDATE` approach inspired from the `ir.sequence`, or even a true UPDATE, we can use a constraint approach. SELECT FOR UPDATE ================= By doing a FOR UPDATE NO WAIT, we are throwing an exception when another transaction is creating a move using the same sequence as this one, by locking the row that holds the current greatest sequence. Since the row doesn't change, the lock is released and the following UPDATE is allowed. Because of this, a "useless" UPDATE was always done on the previous row to ensure a SerializationFailureError if two concurrent transactions were trying to assign the same number. This means that in a database with a lot of concurrent transactions (typically with an online shop), many transactions were aborted/rollbacked. This approach also has the drawback of having the constraint implemented python side, which is less robust. UNIQUE CONSTRAINT ================= Using a constraint on the database level means that the database knows when some transactions will try to do something similar. It will therefore make the concurrent transactions wait instead of aborting the transaction. It is however harder to have the constraint customized by different modules/localization because it is now done directly in the database and not in python. Changing the constraint means deleting/recreating the index. For now, this only happens for Latin America l10n, so a simple hardcoded approach is implemented. In order to achieve this, the business code is trying to use the sequence incrementally until it gets a number it can use for when multiple transactions are concurrent. closes odoo/odoo#106325 X-original-commit: 4b430f8e30efb15f06982e4673cd73531a2119b3 Related: odoo/enterprise#34297 Signed-off-by: Quentin De Paoli <qdp@odoo.com> Signed-off-by: William André (wan) <wan@odoo.com>
3 lines
56 B
Python
3 lines
56 B
Python
from . import account_move
|
|
from . import sequence_mixin
|