Searching on a domain like `[('m2m.sub', operator, value)]` currently does
something like:
right_ids = comodel.search([('sub', operator, value)]).ids
table_ids = model.search([('m2m', 'in', right_ids)]).ids
and reduces the domain triple to `('id', 'in', table_ids)`.
The domain triple can actually be reduced to `('m2m', 'in', right_ids)`. With
this reduction, the search on the field `m2m` will be done as part of the main
query. And this will also enable the optimization of the former fix!
Avoid pathological performance issue caused by injecting ids retrieved with
another query.
Consider a domain like `[('m2m', 'in', ids)]` on a many2many field. The
current implementation will perform the subquery:
SELECT m2m_id1 FROM m2m_table WHERE m2m_id2 IN (ids)
and inject its result into the main query as:
SELECT id FROM ... WHERE id IN (result_ids)
The latter may be very slow if `result_ids` is a huge list of ids.
The fix injects the first query into the main query as:
SELECT id FROM ... WHERE id IN (
SELECT m2m_id1 FROM m2m_table WHERE m2m_id2 IN (ids)
)
As a result, the database will typically JOIN both tables, and avoid generating
the whole list from the subquery.
The reverse field of a one2many could be originating from an
inherits'd field, this was solved in some instance with f5e5bbda.
The issue could still happen in some instances when doing a comparison
of:
- the one2many field to a False value,
- the one2many with a negative operator and an empty set to negate,
With this change, the ORM is used in such a situation.
closes#15234
opw-704962
* Failing test for one2many [(5,)] action, when domain is callable.
The problem is that `self` inside a callable domain becomes the comodel when at [(5,)].
* [FIX][fields] Make [(5,)] with computed domain work.
To reproduce this failure, declare a field like:
```
child_ids = fields.One2many(
comodel_name="other.model",
domain=lambda self: [("id", "in", self._ids_to_find())],
)
```
Now set some value to it.
Now unset them. Impossible because ``self`` becomes ``other.model`` in domain evaluation.
This case corresponds to searches like `[(field, 'ilike', name)]` where `field`
is a many2many field. The domain processing performs a `name_search` on the
field's comodel, then makes the relation match the returned record ids.
Problem: the call to `name_search` uses the default limit (100), and this makes
the search return less results than expected. Make the search complete by
forcing `limit=None`.
The result of searching on a o2m field for a missing ID was
the whole set of records which do not have any lines in the
o2m fields. This is definitely not the desired behavior,
and could lead to disatrous performance, because the
returned set could be extremely large.
One example of such behavior is for recomputing fields
in the env cache in 8.0+. When a o2m line gets deleted,
it triggers the recompute of any dependent fields.
In order to locate the records to recompute, the ORM
searches for the 'parent' records in the comodel table.
When this operation is done by 2 users concurrently
the o2m line may not exist anymore, and the bug
is triggered: dependent fields are recomputed on a possibly
very large set of records that did not need any recompute!
Borrowing a cursor each time you access `field.digits` may be costly, because
of the connection reset. Moreover, in most cases, the cursor is not used at
all, since the decimal precision are kept in cache.
For the installation of module `product` with its demo data, the number of
cursor allocations was reduced from ~1500 to about 50!
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
Backport of de3b64018a
When a new column has been added after that some data already exists,
the old lines will keep an empty/null value. So when we search is the new field
is equals to False or if it is different of True, we need to match the null
values.
close#9925
The current code when applying negative operator on an expression used
recursion which in extreme case is not best friend with python.
e.g: on instance with a lot of wharehouse, some simple action could lead
to a domain with lot of elements which could easiliy go over the python
maximum recursion limit.
This commit fixes this by replacing recursion with iteration.
We have a stack of negation flags and loop on each token of the domain
as follow :
- when we iterate on a leaf, it consumes the top negation flag,
- after a '!' operator, the top token negation is inversed,
- after an '&' or '|' operator, the top negation flag is duplicated on
the top of the stack.
closes#9433
opw-653802
In the `product.template` model,
when searching products within a category that doesn't exist,
all products were returned, while none should be returned.
For instance,
In Sales > Products,
In the search input, search with internal category:
"A category that doesn't exist",
all products were returned.
opw-649548
In 5efac22043 and
1cf5723835 the computation
of the decimal precision of float fields was modified to
reuse a random cursor from the request environments.
Environment.envs is a WeakSet, subject to unpredictable
garbage collections.
This could cause hard-to-diagnose problems by executing
a SELECT query in a cursor that is supposed to be
otherwise idle and untouched.
As an example, this could cause a transaction start in a
cursor that was just committed/rolled back,
and was waiting for another operation to complete.
One such case happened semi-randomly during a module
installation triggered from the web client, where the request
cursor is committed and waiting for the registry
initialization done with a different cursor,
in the middle of _button_immediate_function()
After the registry initialization, the request cursor is
used again to determine the next action (ir.actions.todo),
and this could cause a TransactionRollbackError if the
request cursor was used during the initialization.
Using a new cursor every time is much safer, simpler,
and will not cause any significant performance hit,
because it will usually grab an available connection
from the connection pool, rather than create a new one.
Fixes opw-649151
When linking a record into a `one2many` relation with command `(4, rid)`, a
query checks whether the record is already linked to the current record id:
SELECT 1 FROM {inv_table} WHERE id={rid} AND {inv_field}={id}
where `inv_field` is the name of the inverse field, and `inv_table` is the
table where this field is stored.
The query is wrong if the inverse field is inherited, because the `rid` does
not belong to the table `inv_table`.
The test has been replaced by a plain ORM access:
rec = obj.browse(cr, SUPERUSER_ID, rid)
if int(rec[inv_field]) != id:
...
This fixes#4685.
Postgresql has a limit of 64 characters for tables, columns names
as well as for aliases names.
When generating an alias name, e.g. for group by and order
by clauses, if the alias is longer than 64 characters,
use hashing to force the alias length to be within this
64 chars limit.
Fixes#8094Closes#8142
Consider the following setting:
- on model A, field F is computed, stored, and depends on field G
- on model A, field one2many G to model B, with inverse field H
- on model B, field many2one H is inherited (_inherits) from model C
- on model C, field many2one H is stored
When adding records of model B, the field F must be recomputed. In order to
determine which records to recompute, one searches model A with a domain like
[(G, 'in', ids)]. In expression.py, this is resolved with an SQL query like
select H from B where id in {ids}
This query fails, since the field H is not stored in model B. This happens in
general if H is not stored (it may be any computed field). In that case, one
should instead browse records from B, and read field H through the ORM.
A test case has been added: it introduces a many2one field in a parent model,
and a one2many field using the inherited many2one on a child model. The test
checks whether one can search on the one2many field.
When ordering results on a many2one fields, results are ordered by
order of the target model. The code was wrongly assuming that this
`_order` attribute only contains `_classic_read` fields (that can be
directly read from the table in database). Now correctly generate the
"ORDER BY" clause using the current table alias.
`res.users` can now be sorted by name.
This regex is used for a quick sanity check of
the order_spec in `search(order=<order_spec>)`.
Because it was build on the repetition of a
group ending with a series of optional patterns,
it could cause expensive backtracking when the
order spec did not actually match the regex
(the regex engine was trying all possible ways
to split the groups)
Forcing the repeating group to either end
with a comma or the end of the string prevents
prohibitive backtracking, while being even
more restrictive with regard to the syntax of
the order spec.
Closes#7755
In version 8.0, postgresql's pg_size_pretty function is used
(http://www.postgresql.org/docs/9.4/static/functions-admin.html) when
getting the size of a binary field when reading if `bin_size`
or `bin_size_[col_name]` is set in the context.
So in 8.0 the size of a binary field get units bytes, kB, MB, GB and TB
which was not taken into account. e.g: '5.3 GB'.
This fix uses the size of the string to choose to differenciate the two.
e.g: '10000 bytes' (the longest size) will be returned directly, but
for something longer the human size of the content length will be
returned.
There is a corner case if a file is shorter than 12 bytes but
it is an enough of a small scenario with small implications that it is
deemed acceptable.
closes#7485
opw-644085
In 7.0, a field overriding an inherited model would overwrite all the
previously set field attributes. In v8 the new API allow us to keep
previous attribute, and only overwrite attributes of our wish.
Following the commit 7b1ef708 (october 2014) an old api field overriding
could conserve previous attributes values in some cases (if the new value
is falsy (None, "", 0, False, (), {}, [], ...) when it should not. It
was partly an optimization to diminish the size of orm registries
dictionaries to save memory (this patch has been tested with all odoo
modules and added +/- 3M).
This commit (proposed by rco) should overwrite falsy value (so the
behavior of v7 for old api fields overwritting is re-introduced) and
get back the behavior of old api in V7.
closes#7035
opw-639712
Thamks to parent commit, `request.env` doesn't raise `AttributeError`
anymore for requests without session bound to a database.
This exception was bubbling up to `digits` property (and `__getattr__`)
This reverts commit 49cb46fb78.
This reinstate commit eeedd2d9f5.
This reverts commit eeedd2d9f5.
This revision introduces an issue more serious than the ones
it fixes. This is no longer possible to receive an email
aimed a sale.order thread with catchall.
To reproduce the issue:
- Create a new sale order
- Send a message in the thread to the customer
- Reply to the mail received in the customer mailbox
- Traceback, AttributeError: digits
opw-640370
When setting a custom filter with as domain
[(0, '=', 1)]
the domain was rejected, because (0, '=', 1) wasn't
considered as a valid leaf, while it is.
This is because the Javascript converts this domain
using list instead of tuple
[(0, '=', 1)] -> [[0, '=', 1]]
And therefore, comparing the "list" leaf
to the TRUE/FALSE leaf tuple failed.
Ensuring "element" as a tuple solves the issue.
opw-640306
Christophe Simonis
Raphael Collet
Nicolas Lempereur
Jairo Llopis
Raphael Collet
Olivier Dony
Cedric Snauwaert
Yuriy A. Apollov
Holger Brunn
Jeremy Kersten
Denis Ledoux
Thomas Rehn
Daniel Reis
Laetitia Gangloff