Previously, when a reward was applied on a product, the product was
checked against the reward_product_ids field, which is a computed m2m
field that contains all the IDS of the products on which this reward is
available. In many cases, rewards are available on all products, causing
the computation of the m2m to fill it with the ids of all products.
This caused performance issues on all DBs with lots of products (~200k)
in all flows involving rewards.
We can't remove reward_product_ids from the data loaded in the frontend
in stable because existing JS customisations might crash if they depend
on its presence. As such, to keep compatibility with existing databases,
an ir.config_parameter has been introduced to opt into the new
behaviour. This parameter is set when creating a database so that new
databases don't suffer from this performance penalty.
For existing databases, the parameter can be set by hand if the old
behaviour is not necessary and the performance penalty is an issue in
practice, but is unset by default.
When opting into the new behaviour, the reward_product_ids field now
always evaluates to an empty recordset, and the desired behaviour should
be achieved by evaluating records against the reward_product_domain
instead. In the point_of_sale, the products available on rewards are
calculated by evaluating each product against the reward when it is
loaded. In the loyalty modules, instead of using the in operator on the
reward_product_ids field, we instead evaluate the reward product domain
against the product, which is much faster. This is always done even when
not opting into the new behaviour as the change in implementation cannot
be observed outside of timing.
closesodoo/odoo#120074
X-original-commit: 6f72d053a31aca520cbfbba2d1257568b7f7c0cb
Related: odoo/enterprise#40503
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
David Monnom (moda)
bec5c746b4