[FIX] stock: product.stock_move_ids triggers performance problems when used on api.depends #91252
Conversation
|
and what about adding |
|
@MiquelRForgeFlow |
|
But if those non-stored fields appear in the form view, then you may want that they get updated. Without the api.depends, the value will not be updated in the form view. Right? |
|
@MiquelRForgeFlow they will, but just when you ask for them. |
…n used on api.depends api.depends should not be used on computed fields that are not stored = True In order to avoid forcing it computation when aren't consulted Consider the following scenario: - Configure MTO products - Sell the product - Confirmation will trigger the creation of MO and its stock.moves and will confirm them. This is an exponential issue since we will see the performance issue once we got at least 50K records on stock.move for each product that it's a component on BOM. Every time we wrote in a move, (by processing the MO of that product or processing the moves of the pickings of that product) the api.depends on _compute_quantities method, forces it to calculate the available quantity when it is not really necessary because the fields that uses that computed method are store=False and they aren't be consulted.
hugho-ad
force-pushed
the
15.0-mrp-qty-available
branch
from
90bc3e7
to
4deae8c
Compare
|
ping @odony |
|
@hugho-ad Hello. The computed fields should not be recomputed in the same transaction unless the value is read as you mention. Are you sure you are not triggering the compute by the next MO (or picking) read that follow the validation to refresh the view ? This may be due to the availabilty widget on stock moves list view |
api.depends should not be used on computed fields that are not stored = True
In order to avoid forcing it computation when aren't consulted
Consider the following scenario:
This is an exponential issue since we will see the performance issue
once we got at least 50K records on stock.move for each product that
it's a component on BOM.
Every time we wrote in a move, (by processing the MO of that product or
processing the moves of the pickings of that product) the api.depends on
_compute_quantities method, forces it to calculate the available quantity
when it is not really necessary because the fields that uses that
computed method are store=False and they aren't be consulted.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
OPW 2852585
--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr