diff options
| author | Michael Brown <mbrown@fensystems.co.uk> | 2016-08-15 02:18:39 +0100 |
|---|---|---|
| committer | Olivier Dony <odo@openerp.com> | 2016-10-06 13:02:52 +0200 |
| commit | 1b3d60d961bd9b79d877ba8e69c2b9495d5aa442 (patch) | |
| tree | 641777557fb98485c4c2a43019a8b9acef043095 /addons/web_editor/static/src/less/web_editor.ui.components.less | |
| parent | 10dcec1e9af583e2a41acbe3a4676884daf79d76 (diff) | |
[FIX] product: speed up product.template bulk record creation
Bulk inserts of product definitions (e.g. via a CSV import) will
suffer from an O(n^2) performance penalty due to an unfortunate cache
invalidation bug. The underlying cause is difficult to determine due
to the labyrinthine nature of the relationship between product.product
and product.template, but some key elements are:
- The "product_variant_count" field is a non-stored computed field,
and so gets invalidated by the call to recs.modified(upd_todo) in
BaseModel.create()
- Field.determine_value() will call _prefetch_field() to repopulate
"product_variant_count" by refetching all records from the database,
despite the fact that "product_variant_count" is not stored in the
database.
Using the length of "product_variant_ids" directly (instead of going
via "product_variant_count") seems to avoid this problem, possibly
because the definition of "product_variant_ids" conveys more
information about the circumstances in which its value must be
invalidated.
An alternative solution of making product_variant_count a stored field
(using the same trigger as for other variant-derived fields such as
volume and weight) works but still results in some unnecessary fetches
and invalidations.
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Closes #13689
Diffstat (limited to 'addons/web_editor/static/src/less/web_editor.ui.components.less')
0 files changed, 0 insertions, 0 deletions
