Reduce memory footprint of server
The tricks used are:
- use a global LRU for `ormcache` (auto-balancing between registries);
- remove unnecessary data structures (binary class hierarchy of models);
- compute some data structures on demand (`_all_columns`);
- optimize field attributes (empty collections may be shared);
- optimize memory size of fields and columns by using slots.
On a database with modules sale, purchase and stock installed, the memory footprint of the registry went from 20.3Mb to 7.4Mb (as measured with heapy). In other words, the memory footprint was reduced to 1/3 !
In ormcache, those statistic numbers were counted per cached method for all
registries. We introduce separate statistic counters, and create a counter per
(database, model, method). The existing attributes that are no longer used
have been removed.
The registry size is now assumed to be around 10Mb, and ormcache size is
proportional to the maximum number of registries. Statistics about ormcache
usage is shown to the log when receiving signal SIGUSR1.
In `__getattr__`, remove the test on accessing `_attrs`. This situation should
never happen, since the attribute `_attrs` is set in method `__init__()`.
Introduce slots on all field classes for common attributes; slots take much
less memory than a `__dict__`. The other attributes are stored in a dictionary
`_attrs`; all fields with an empty value for `_attrs` (common case) share the
same empty dictionary. This saves quite some memory (around 4.5Mb per
registry), given the number of field instances created for a registry.
Another mechanism is used for the default values of attributes, since slots
cannot be assigned on classes.
The optimization consists in using tuples for attributes `inverse_fields`,
`computed_fields` and `_triggers`, and to let them share their value when it is
empty, which is common. This saves around 1.8Mb per registry.
This saves about 400Kb per registry by not allocating those lists, which are in
most cases empty. The removal of the attribute will also simplify a bit the
management of free attributes.
The computed value of parameter digits is no longer stored into fields and
columns; instead the value is recomputed everytime it is needed. Note that
performance is not an issue, since the method `get_precision` of model
'decimal.precision' is cached by the orm. This simplifies the management of
digits on fields and saves about 300Kb per registry.
Sometimes, the expected mro of the model is not the same as the one built with
a binary class hierarchy. So we reorder the base classes in order to match the
equivalent binary class hierarchy. This also fixes the cases where duplicates
appear in base classes.
Instead of composing classes in a binary tree hierarchy, we make one class that
inherits from all its base classes. This avoids keeping intermediate data
structures for columns, inherits, constraints, etc. This saves about 600Kb per
registry.
The mappings model._all_columns takes quite some memory (around 2MB per
registry) because of the numerous dictionaries (one per model) and inefficient
memory storage of column_info. Since it is deprecated and almost no longer
used, it can be computed on demand.
The ormcache is now shared among registries. The cached methods use keys like
(DBNAME, MODELNAME, METHOD, args...). This allows registries with high load to
use more cache than other registries.
QWeb templates can be translated, javascript code
included. Nothing prevents you to translate
the javascript reserved word "undefined", for instance.
Preventing the livechat JS snippet to be translated
prevent translations mistakes, like translate
```undefined``` by ```Niet gedefinieerd```
opw-630335
The same holds for the inverse history_ids relationship. When an object is copied,
the many2many fields their links are copied.
When we copy a done move as is done in the return wizard to create the reverse, it copied also
the relationship with the quants. This is problematic as this field indicates the quants that
were transferred by the move and the new move will think it will have returned all the quants
even before it is done.
Currently, the view_form search_count doesn't propagate the context, so when
searching on a translated field, the count can be different than the one we
would expect and get with a search in a current language different than en_US.
opw-628792 opw-630212 closes#5825
`product_qty` field is not recomputed at record creation.
Force field recomputation at any change
Removing the trigger on `product.product` should not be a problem as
product uom can't be changed once there are move lines.
opw:629650
This will allow to speed up our migration platform: as funzip can pipe
the output of the first file of the archive, even if the file is not
fully unzipped yet. This is useful to plays with dump.sql without waiting
for the full archive decompression.
When a `noupdate` record is processed during an update,
the update_dummy method marks the record as "seen" so
it won't be deleted at the garbage collection step,
and seen as an obsolete external ID.
This needs to be done also for the parent records via
_inherits, because they have also received an implicit
external ID at creation, and must not be garbage
collected, even if their `noupdate` flag (db side)
is not set because the flag was added later.
This rare problem could be reproduced by creating a product
in a module, then referencing it in e.g. a sales order,
then updating the module after changing the product
record to be in a `noupdate` block.
At the end of the update the implicit product.template
record would be garbage collected, and trigger a cascade
deletion of its children - blocked by the SO reference
to the product.
This temporary patch was used to simulate the presence of a
`display_name` field in all models. It is not needed anymore
as of version 8.0, which comes with the actual magic to make
`display_name` work everywhere.
Improve commit bf31ab6718a8b9c8afdd29120e5056533b0a2ade:
- do not use the product.product name_search() when there is no
search term (it's only useful with a search term
- do not use the product.product name_search() when the extra
domain (args) has a criterion on IDs - these will be *template*
ids, not *variant* ids, so the results would be wrong
- Since templates and variants use a different natural `_order`,
perform an extra name_search() on templates after gathering the
ids to return, to apply the proper sort ordering. Increases the
penalty by doing 2 name_search() calls.
This issue could be seen e.g. in the breadcrumbs where the
display_name variable is displayed for templates, and indirectly
relies on name_search() due to an old hack in call_kw in order to
implement the "future_display_name".
a6eac0f08e introduced a new `res.groups`
belonging to the "Sharing" category.
As this group has the flag `shared`, it is ignore when generating the
group's user view (and its virtual fields).
When updating `mail` module, the `share` module (which depend on mail)
is not loaded yet. This mean this new group is taken into account when
getting the `res.users` virtual fields.
As this group belong to the same category as the `share.group_share_user`
group but dont have an inheritance link between them (`implied_ids`),
they are generated as `boolean` instead of a single entry `selection`
field. This create a missmatch between the fields and the previously
generated view, which forbid inheritance application.
Force view regeneration, to avoid it.
Also change the group's category as this group is purely technical and
must be hidden anyway.
When the theoretical_qty of the stock is calculated, we should only consider the location itself, not its children.
That way you can have correct inventory for e.g. iPads that are both in Stock and Stock/Shelf 1
During the creation of a Sale Order containing a product for which 'Make To Order' is activated
in the Procurements, two procurements are created:
- one for 'Partner Locations/Customers' location
- one for 'WH/Stock' location
If the Sale Order if cancelled, the user must first cancel the picking (delivery order).
This will trigger the cancellation of the procurement with the 'Partner Locations/Customers'
location.
The new behavior is to cancel the procurements linked to the Sale Order, which will trigger
the cancellation of the picking.
opw: 630170
issue: https://github.com/odoo/odoo/issues/3805
The invalidation in registry was done only if the field's model was already in
registry. This situation is not the case when you create a custom model with a
custom field.
Goffin Simon
Anton Chepurov
Raphael Collet
Denis Ledoux
Josse Colpaert
Christophe Simonis
Nicolas Lempereur
Nicolas Piganeau
Nicolas Martinelli
Dharmraj Jhala
Olivier Dony
Antony Lesuisse
Jeremy Kersten