Before this commit if a computed field is already in cache, but not its
dependencies, `fetch` would fetch those dependencies.
This commit ensures that fetch checks first if a computed is in cache
before fetching its dependencies.
This commit also follows dependencies of computed fields, if they depend
on other computed fields.
Finally, this commit consolidates `fetch` and `search_fetch`:
they should use the same heuristics to know which fields to fetch.
closesodoo/odoo#120001
X-original-commit: 6b680c463956f929db10d4c3058c36112a67e674
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: rco-odoo <rco@odoo.com>
a new context `prefetch_langs=True` allows ORM to prefetch all translations of
translated fields while fetching.
For example
The activated languages are 'fr_FR' and 'nl_NL'
In the database the value is '{"en_US": "English", "fr_FR": "French"}'::jsonb
after fetch with `prefetch_langs=True` the raw cache value will become
{'en_US': 'English', 'fr_FR': 'French', 'nl_NL': 'English'}
closesodoo/odoo#116947
Signed-off-by: Raphael Collet <rco@odoo.com>
On a model X, where there is a field related x_related
(related= 'y_id.y_translate') towards a translate field y_translate
on Model Y.
When you unlink at least 1001 records of X
(r1, r2, ... , r1000, r1001) (cr.MAX_IN + 1), you get a traceback
(`RecursionError: maximum recursion depth exceeded in comparison`).
The stack looks like:
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3609, in unlink
self.env.flush_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 732, in flush_all
self._recompute_all()
File "/home/odoo/Documents/dev/odoo/odoo/api.py", line 728, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6179, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4209, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5874, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2771, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3214, in _read
self.flush_recordset(translated_field_names)
...
-> Extra info:
translated_field_names = ['x_related']
`self = X(r1001, r1, r2, ..., r999)`
...
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5585, in flush_recordset
self._recompute_recordset(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6162, in _recompute_recordset
self._recompute_field(field, self._ids)
...
-> Long recursion starts here but first records to be recomputed will be r1, then r2, then r3, ...
But the maximum recursion depth error will be triggered earlier at the
end of the recursion, because the stack limit in Python is 1000
by default.
...
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 6179, in _recompute_field
field.recompute(records)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1348, in recompute
self.compute_value(record)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1368, in compute_value
records._compute_field_value(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 4209, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 100, in determine
return needle(records, *args)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 689, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 5874, in __getitem__
return self._fields[key].__get__(self, type(self))
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 2771, in __get__
return super().__get__(records, owner)
File "/home/odoo/Documents/dev/odoo/odoo/fields.py", line 1186, in __get__
recs._fetch_field(self)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3162, in _fetch_field
self._read(fnames)
File "/home/odoo/Documents/dev/odoo/odoo/models.py", line 3214, in _read
self.flush_recordset(translated_field_names)
...
------ Extra info:
translated_field_names = ['x_related']
`self = X(r1, r2, ... , r999)`
...
Since 9c3b9a4926, the `x_related` is
flagged to be recomputed at the end of the delete
loop of `unlink`, but it shouldn't be, because records are deleted now.
The problem is in these lines:
```python
with self.env.protecting(self._fields.values(), records):
self.modified(self._fields, before=True)
```
The `records` are only a part of `self` (batch of 1000), so the
`protecting` call only protects the current batch and not `self`.
Then, the second batch (here with only one record), will flag to recompute
`x_related` of the first batch records. Then, later on, the `flush_all`
will generate the recursion error trying to resolve
these `to_recompute`.
To fix it, only move the modified call (+ protecting) before
the batch loop and executes it on `self`.
This issue shouldn't exist in master, because having a
related translate field triggers a warning (`Translated stored related
field (<field_name>) will not be computed correctly in all languages`).
Also `https://github.com/odoo/odoo/pull/100472` fixes the issue in
master, but it generates one SQL request by record, which isn't great.
Then in master, we should forward this commit (but test will be remove
because it generates the warning message).
closesodoo/odoo#119471
X-original-commit: 78450cae5900e267de439e4988b314aa644e76bd
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
Before 916c9c46f58f27c68c5558a2a57fdca43a89fe89, we could
groupby several times on the same relational field with `read_group`
Example: `read_group(..., groupby=['product_id', 'product_id'], ...)`.
Now, it produces a traceback:
File "/data/build/odoo/odoo/models.py", line 2583, in read_group
self._read_group_format_result(rows_dict, lazy_groupby)
File "/data/build/odoo/odoo/models.py", line 2396, in _read_group_format_result
ids = [row[group].id for row in rows_dict if row[group]]
File "/data/build/odoo/odoo/models.py", line 2396, in <listcomp>
ids = [row[group].id for row in rows_dict if row[group]]
AttributeError: 'tuple' object has no attribute 'id'
It is because `_read_group_format_result` try to convert the record
into tuple (id, display_name) twice (one for each groupby).
Fix this issue introduced by the refactor of `_read_group`.
Part-of: odoo/odoo#119459
Calling `fetch` with computed fields will also check that the dependencies
of those fields are fetched, which is good.
This commit adds a check that verifies that all the dependencies are already
fetched before re-fetching them.
closesodoo/odoo#119247
X-original-commit: 7ab724450c9aa29ad6c1739cff1e928d79666dac
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Calling `fetch` with 'id' in the `fields_name`, will always generate
SQL query even if all requested field values are in the cache.
This is because we also look for values in the 'id' field cache,
but we don't ever fill the cache for `Id` fields.
closesodoo/odoo#119107
X-original-commit: 3ba8d0e5e57e1358cc8958abf511d514515eccb2
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Make the public `read_group` depends of its private method `_read_group`
refactored to match the backend usage.
We try to keep the public API similar for this first part of the
rafactor, but there are still some API change:
- We cannot order by `id` anymore.
- The display_name of many2x group values are not lazy anymore.
Part-of: odoo/odoo#110737
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
The `_read_group` was designed to be used by the web client to
efficiently compute aggregations grouped by one or more fields.
However, more and more developers have been using it from the backend
to make computations more efficient (avoid doing the aggregation
in Python). Unfortunately, the API was designed for the web client,
which added a lot of boilerplate when used in the Python (list of
dict with misleading key name choices).
`_read_group` was created to improve the performance of read_group
for backend use (4ef0c00b4b), but didn't
change the API and based the implementation on read_group itself.
Rewrite `_read_group` from scratch with a new API to make it easier
to use from the backend (see the method documentation). Also, split
the method to make it easy to override and add custom behavior.
Part-of: odoo/odoo#110737
As a developer,
when you craft your records set manually,
and wrongly use the API and set something weird in `ids`,
something else than a tuple of integers,
`repr` should help you to understand you did something wrong.
e.g.
before
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner(1,)
```
after
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner'(1,)'
```
We could put an assert in `_browse` to make sure `ids`
is a tuple of integers, but this is considered a non-stable
change, as it will suddenly crashes when you will update
Odoo while it wasn't the case before.
closesodoo/odoo#118119
X-original-commit: f689c4f53fc4663b17c57bd1d704b9ffb9f11f8d
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Recent Odoo versions require modern postgres (e.g. use of jsonb), the
`NULLS {FIRST | LAST}` clause was added in 8.3 so should be well
supported.
While Odoo's use of nulls is not always consistent, the NULLS ordering
clauses can be quite useful especially when sorting `DESC`: `NULLS
FIRST` and `NULLS LAST` are literal positions so they put nulls at
that location regardless of sort order whereas the default Postgres
ordering is to consider nulls larger than every other value so they
appear first when sorting DESC, which is often undesirable (putting
nulls first when sorting ASC can also be useful to fill records).
Update `_generate_order_by_inner` to correctly process `NULLS` clauses:
- Use `regex_order` to ensure we parse orderings correctly and
consistently, also update `regex_order` to use named groups to make
the relevant bits clearer (and VERBOSE for readability).
- Given `a_id DESC` and `_fields[a_id].relation._order = 'xxx NULLS
LAST'`, reversing the clause should order by `xxx DESC NULLS FIRST`
to correctly flip the original as `NULLS` clauses are not relative
to the sorting order (they put the `NULL`-valued records at the
specified location regardless). Therefore apply `reverse_direction`
to `NULLS`.
- Manually expand `NULLS` clauses on m2o fields: propagating the
clause through the join would yield unexpected and illogical results
when mixing NULL m2o fields and non-NULL m2o fields with NULL
`_order` fields (as they would get mixed rather than clearly layered
/ separated).
However because SQL booleans are ordered the usual way (`true >
false`) the `NULLS` clause is fundamentally equivalent to sorting on
the field being NULL (if `NULLS LAST`) or not (if `NULLS FIRST`). So
we can prepend the expanded m2o's ordering with such a clause to get
the correct behavior.
Replaces #116464
Supersedes #116664closesodoo/odoo#117439
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Petar Najman <petar.najman@modoolar.com>
As we have a team dedicated to work on analysing tracebacks
with sentry, and to takedown all tracebacks occuring on the saas,
we do an effort to avoid unecessary warnings and tracebacks
for both sentry and the runbot.
closesodoo/odoo#112101
Signed-off-by: Rémy Voet <ryv@odoo.com>
This fixes an issue with an override of onchange() on account.asset,
which asks for less fields to be considered in the snapshot. This also
guarantees that onchange() does not return values for unexpected fields.
Part-of: odoo/odoo#116779
after odoo #113888
when copy translations from one record to another, translations for
non-installed languages may raise error.
These translations may be
1. created before the langauge is deactivated
2. en_US which is always available for non falsy translated field value
this commit drops translations for uninstalled languages except 'en_US' when
copy and prevents raising error when users want to translate en_US when en_US is
not activated
closesodoo/odoo#115711
X-original-commit: 7bb1825ddbf2340882bef5ed1d9c877f78a2b815
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
This commit adds a check to prevent saving a translation in a language that was not installed.
Upon adding a translation, the field "language" in the request was not checker,
allowing to add translation for language (or any strings as key) for a given field
This is not ideal and we want to prevent that, it can bloat the database for no reason.
opw-3208305
closesodoo/odoo#114793
X-original-commit: 89cd5ce88a0c666e811410e264e3cb474f9851c0
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Purpose
=======
Allow to search properties fields.
For now, the properties fields are meant to be used with the frontend
top bar filter on views in a later commit, and so everything as been
kept as simple as possible for that particular use case.
Technical
=========
Relational properties
---------------------
We can not search on relational properties using the rec name, or
using one of their fields.
The following domains do not work
```
[('properties.partner_id', 'ilike', 'alice')]
[('properties.partner_ids', 'ilike', 'alice')]
[('properties.user_id.name', 'ilike', 'bob')]
[('properties.user_ids.name', 'ilike', 'bob')]
```
Instead, we should give the ids
```
[('properties.partner_id', '=', 55)]
[('properties.partner_ids', 'in', 55)]
```
IN operator
-----------
The "in" operator is used to either search specific tags / many2many
values, either doing a "OR like" condition on "non-array" value.
It can be used if the left or the right side is not an array
```
[('properties.my_char', 'in', ['a', 'b'])]
[('properties.my_tags', 'in', 'a')]
```
But it can't be used if both side of the condition are array, because
it will require to check type in SQL (which is technically possible,
but add extra complexity, so for now we keep the feature as simple as
possible).
So the following domain is not supported.
```
[('properties.my_tags', 'in', ['a', 'b'])]
```
Instead we should use the "OR" operator
```
['|', ('properties.my_tags', 'in', 'a'), ('properties.my_tags', 'in', 'b')]
```
Tags / many2many - "=" operator
-------------------------------
Tags and many2many have to be searched using the "in" operator.
So the following domain will return unexpected results and raise a warning.
```
[('attributes.mytags', '=', ['a', 'b'])]
```
The reason is that we don't want to dynamically check the type in SQL,
and so we need the "in" domain operator to know what to do in SQL.
Task-2980121
Part-of: odoo/odoo#101901
Purpose
=======
Do not modify the cache in order to improve the performance when we
read in batch. Instead we create a new batched method "convert_to_read"
that check existence in batch, and generate a dict with the result.
Now, all the properties field checks (many2one existence, selection option
still exists, tag value stiff exist, etc) and done in "convert_to_read".
It means that doing `record.properties` won't do all those checks.
Having the batched field fetch at the convert_to_record required too
many changes for the scope of this task, so "record.properties" having
the cache values unchecked is an acceptable tradeoff currently, hence
we batch convert_to_read.
Task-2980121
Part-of: odoo/odoo#101901
This fulfills the goal of searching and fetching fields in a single SQL
query. We introduce the new method search_fetch() for that purpose.
Also introduce method fetch() to fetch some fields for a recordset if
they are not in cache yet.
The call graph is as follows:
search() calls search_fetch()
search_read() calls search_fetch() and _read_format()
read() calls fetch() and _read_format()
search_count() calls _search()
search_fetch() calls _search() and _fetch_query()
fetch() calls _search() and _fetch_query()
The methods _search() and _fetch_query() are usually the ones to
override to implement business-specific logic. The method _search()
returns a Query object to retrieve the records that satisfy the given
domain and are accessible for reading. The method _fetch_query() uses a
Query object to retrieve fields from the database and store them in
cache.
Also use search_fetch() to save one query in search_read() and the
reading of one2many fields.
Part-of: odoo/odoo#112126
Goal: make _search() always return a Query object, in order to make
search_read() in a single query when possible
Adapt the overrides of _search() towards the given goal.
Part-of: odoo/odoo#112126
This API is much more sensible for making subqueries. Specifically, one
can generate a subquery without the clauses LIMIT and ORDER BY.
Part-of: odoo/odoo#112126
This simplifies the use of subqueries by avoiding some costly default
order on the model or the idiotic order='id'. Method _flush_search()
has been adapted accordingly.
Part-of: odoo/odoo#112126
The parameter in search() is redundant with method search_count(), and
was making the calls less readable.
The method _search() is aimed at always returning a Query object. The
method can therefore never return an integer, hence the removal of the
parameter. This does not actually remove any functionality from the
method; counting result is simply given by using it differently.
Part-of: odoo/odoo#112126
A set iteration was creating a random number of queries on some tests.
This was noticed in TestEventPerformance were a random additionnal query
could appear in default_get depending on _get_description and
_get_default_stage_id order.
This commit uses a list to get a deterministic order. It looks like
the set was not useful anyway.
closesodoo/odoo#113563
X-original-commit: 13572df256ccc6351588851d385c381ace155e0d
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Steps to reproduce:
- Make sure language preference is 'en_US'
- In accounting, in the dashboard click on bills
- Filter 'due_date' by week
Issue: The start day is Monday and should be, for 'en_US', Sunday as it
is the case in the dashboard view in accounting (see appendix).
Cause: The query uses the `date_trunc('week', date)` which in Postgres
retrieves the first day of the week as Monday (ISO week).
Solution: Create an offset in the query depending on the first day of
the locale variable.
Note: the `web/tests/test_read_progress_bar.py` has been modified: since
the default language is 'en_US' there will be an offset of one day. To
make it less confusing, I used only two anglo-saxons countries so the
day offset is not the variable tested. (for this matter, pleaser refer
to `test_read_group/tests/test_read_group_process_groupby.py`)
Appendix:
Language (english-US)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W23 -> 06/05 | 05/29 -> 06/04
W24 06/06 -> 06/12 | 06/05 -> 06/11
W25 06/13 -> | 06/12 -> 06/18
(Monday - Sunday) (Sunday - Saturday)
Language (french-BE)
VIEW (per week) | DASHBOARD
___________________________________________________________________
W22 -> 06/05 | 05/30 -> 06/05
W23 06/06 -> 06/12 | 06/06 -> 06/12
W24 06/13 -> | 06/13 -> 06/19
(Monday - Sunday) (Monday - Sunday)
opw-2747066
closesodoo/odoo#93053
Related: odoo/enterprise#29539
Signed-off-by: Raphael Collet <rco@odoo.com>
The field is updated in SQL but not in cache. Also remove hacks in the
business code to prevent potential issues from this behavior.
closesodoo/odoo#113119
X-original-commit: 8bb660c985c7a1349cae1bf58dc5bf7981bd9058
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
Consider field F in module X with parameter translate=False, and F is
overridden in module Y with parameter translate=True. During the
upgrade of module X, module Y hasn't been loaded yet, and the ORM
considers the field to be `translate=False`. Therefore it converts its
database column from type jsonb to varchar, and accidentally drops
non-en_US values:
{"en_US": "English value", "fr_FR": "French value"} (jsonb)
-> 'English value' (varchar)
As a result, translations are lost after upgrade.
This commit fixes the bug by checking whether the field is translated in
database and patches the field accordingly when loading the registry.
This avoids the ORM considering the field as non-translated while
upgrading modules.
In order to "force" translated fields to become non-translated ones, at
the end of the loading process the patch above is discarded, and fields
are checked again. We then adapt the schema of models that have such
fields. This extra step handles the uninstallation of modules like
module Y in the example above.
The patching of the fields has one potential issue. While upgrading
module X, field F is patched with translate=True. If module Y actually
overrides F with translate=xml_translate or so, this may cause the
behavior of the upgrade to be slightly incorrect. Because of the
complexity, we have chosen to not support this case.
closesodoo/odoo#112223
X-original-commit: 1e6e482a9763baa5fae70d9b6676d16a46458f4a
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
Co-authored-by: Raphael Collet <rco@odoo.com>
The class is a simple extension of dict, and adds an explicit attribute
for the content of the root node of a tree. It makes the code much more
readable with very small performance overhead.
closesodoo/odoo#111946
X-original-commit: 8a01d74e5f7d035cfd05bc02596f075270e0fcf8
Signed-off-by: Raphael Collet <rco@odoo.com>
Those APIs are aimed at hiding the implementation of trigger trees,
dependent fields and fields modifying relations. Explicit APIs simplify
the profiling of executions and comparison of implementations for
building trigger trees.
X-original-commit: d12b9270375634e738f5288d0c523ac0eec2fa18
Part-of: odoo/odoo#111946
Before this commit, there is no way to "void" model translations, i.e.,
discard a translation and let the value fall back on the 'en_US' value.
The API of methods write() and update_field_translations() can only
overwrite the translations for the specified languages.
After this commit, calling update_field_translations() with a falsy
value except the empty string discards the corresponding translation
value, and let the value of the field in the given language fall back on
the 'en_US' value of the field.
X-original-commit: 5434fb845c393327db377abf872c448f4860a7d3
Part-of: odoo/odoo#111869
model/model_terms translations:
A transifex link if available is displayed after the language in the translation
dialog to help translators to contribute their translations. The tooltip message
for mouse hovering is 'Contribute'
code translations:
Setting -> Translations -> Application Terms -> Transifex Code Translations
In order to reuse the list view and search bar, model transifex.code.translation
is created to store all code translations.
This model is
1. readonly
2. reloaded on demand/by cron(7 days) to avoid increasing the Odoo restart time
3. updated for new installed modules/languages while opening the list view
4. shared to all users without duplicated translations
closesodoo/odoo#111685
X-original-commit: 7b30badb52e2a948c41f4340a01f6118818c6711
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Wang Chong (cwg) <cwg@odoo.com>
There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.
For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.
Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).
closesodoo/odoo#110370
Signed-off-by: Raphael Collet <rco@odoo.com>
Warn when constrains name combine with table name will be more than
63 characters.
This is to avoid case like the one fixed in #103148
Unlike index, since constrains name are defined in the code, we prefer
to avoid automatic truncate and add a warning since devs can chose
an appropriate short-enough name.
The linked fixes will just truncate the name to the max length
to match the name in existing databases. Renaming could be done in other
pull requests with upgrade scripts to avoid constrains re-computation.
Part-of: odoo/odoo#109065
The revision 65a012c2bba0ed81d9b525a7779c726043b17707 changed the
behavior of method _read() when invoked on a record with id None.
Before the change, the method would consider that no records have been
fetched because the id is falsy. After the change, it keeps the id None
in the fetched records, and attempts to make subsequent SQL queries like
"column IN ()", which is syntactically incorrect.
OPW 3104957
closesodoo/odoo#108785
X-original-commit: 712d03cb2ee5f2fde0e80619be5db38aa09ed1ac
Signed-off-by: Rémy Voet <ryv@odoo.com>
Signed-off-by: Raphael Collet <rco@odoo.com>
This is a rare case where method _read() raises a MissingError instead
of just ignoring it.
The issue is triggered by several conditions on a model M:
- at least one ir.rule on M with a domain using a column field on M;
- one deleted record Y which is in the prefetch set of a record X;
- one reads a non-column field on record X.
Fix method _read() to manage that case. It adds an extra call to
exists() in that case, but adds no overhead in the general case.
closesodoo/odoo#108050
X-original-commit: 1876dc87e5c88c711c9b3882c39be704ffc46532
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Rémy Voet <ryv@odoo.com>
The model terms translations assume the number of terms in each language of a
model_term translated field should be the same.
However, sometimes the assumption cannot be promised for sake of bad
translations
This commit
1. drops illegal model term translations while translating
2. drops mismatched terms at run-time in case the database has been contaminated
closesodoo/odoo#107373
X-original-commit: f9ab5ca3e99b2883ada18a8f6deb12d45608b43f
Signed-off-by: Raphael Collet <rco@odoo.com>
The main goal of this commit is to reduce the size of the registry by
removing the (almost) useless __last_update field.
Statistics # of fields with all modules installed:
before 30184 fields, 1299x last_update (4.30%)
Before this commit, the computed field __last_update was added on every model.
The idea behind this field was to have a computed field that had either
the write_date or the create_date if the write_date was empty. However,
the write_date is always written, even on creation, making it useless
to have the computed field __last_update
After this update, we completely remove from BaseModel:
* __last_update
* CONCURRENCY_CHECK_FIELD that was always defined as "__last_update"
* _compute_concurrency_field that was the compute function for __last_update
closesodoo/odoo#105739
Task-id: 3062140 (part of 3062137 improve registry load time)
Related: odoo/upgrade#4038
Related: odoo/enterprise#33939
Signed-off-by: Raphael Collet <rco@odoo.com>
Sometimes a constraint is too complex to be expressed in the general
`_sql_contraint`.
This allows to hook on a constraint if it matches the name in order to
display a user friendly error message.
X-original-commit: e1f06479a526c703ccabc441b1e194646206b966
Part-of: odoo/odoo#106325
The mapped call is supposed to populate the cache, but that's already
taking care of by prefetching. It ends up adding an overhead instead.
The perf improvement is more noticeable on large recordsets.
For example, on a database populated with 100k res.partner records.
Before:
.. code-block:: python
partners = env["res.partner"].search([])
partners.filtered("name") # warm up
timeit.timeit(lambda: partners.filtered("name"), number=10)
# result: 7.15
After:
.. code-block:: python
partners = env["res.partner"].search([])
partners.filtered("name") # warm up
timeit.timeit(lambda: partners.filtered("name"), number=10)
# result: 4.67
closesodoo/odoo#105350
Signed-off-by: Rémy Voet <ryv@odoo.com>
Rémy Voet (ryv)