diff options
| author | Odoo's Mergebot <xmo+roboto@odoo.com> | 2020-03-09 16:04:48 +0100 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-03-09 16:04:48 +0100 |
| commit | a4e1b7c44e77ad2abf1be05ccffacde65a051822 (patch) | |
| tree | 3708b51994a37a48bd9df04ffbbf78a6ce7a78f1 /addons/web/static/src/js | |
| parent | 0712c5222c8e230e5b582fd70732c04446ce65ef (diff) | |
| parent | e3afe4d067e9e4eec54e0f0eadfd7316ae57dc99 (diff) | |
[MERGE] mail, test_mail: remove aggregation from `message_format`
Remove aggregation from `message_format `and `_message_read_dict_postprocess`.
There should be no functional change in this PR.
Purpose
=======
The existing code working with "tree" for aggregation and doing explicit "read"
or "search" for related fields does not seem necessary since the ORM of v13.
Considering that it adds complexity to the method, if its original purpose is
not necessary anymore, it would be better to change it.
The notable changes of the ORM that would justify this task are:
- single cache, shared between current user and sudo (which is called a lot in
those methods and might explain why the "tree" mechanism was put in place
originally)
- m2o and o2m being kept consistent with each other, which allows accessing o2m
through fields directly (instead of having to use "search" to ensure getting
consistent data)
Explanation
===========
Doing "read" or "search" could be counter-productive if the data are already in
cache because using those methods will lead to a query no matter what.
The ideal way is to simply access the fields through the records.
As for the "tree" and aggregation in general, the prefetch is automatically
taking care of that when iterating.
task-2180311
closes odoo/odoo#43841
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Diffstat (limited to 'addons/web/static/src/js')
0 files changed, 0 insertions, 0 deletions
