Thursday, February 15, 2024
3 changes · 17.0
Enhancements to existing features
This update improves the performance of calendar searches by simplifying how the system filters events. Previously, the system was performing unnecessary database lookups when filtering by related record IDs. The change removes these redundant lookups when they're not needed, making calendar operations faster without affecting functionality.
Original PR description
## Description
Domains of the form
```python
[('stored_Many2X.id', '=/!=/in/not in', list_of_ids)]
```
will force the ORM to generate a sub-`SELECT` (or `LEFT JOIN` in case of `auto_join=True`), which is inefficient, as the `id` can be retrieved directly from the current `model` table, instead of going to fetch it from the `PKey` of the `comodel` table.
There is just one *important* detail - in the sub-select, the `ir.rule` of the `comodel` is applied, which is not the case when directly referencing the `field` from the `model`. So in some cases using an explicit `.id` would be a wanted, if the intention was to apply the `ir.rule`.
## Fix
Remove the `.id` from left leafs of domains that if the field is stored, and the `comodel` doesn't have `ir.rule` associated with it, or the `ir.rule` application is redundant/not needed.
task-3735923
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prA warning message has been added to alert users when importing modules with demo data. This improvement helps users understand the implications of demo data installation and make informed decisions during the module import process.
Original PR description
task-3725221
This update optimizes how the system searches for users when handling complex database queries. Previously, the system would retrieve and process entire user lists even when not needed, causing slow performance on large databases. The fix skips this unnecessary processing when the search doesn't require a specific order, significantly reducing database load and query times.
Original PR description
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a…
## Description When searching with a domain that contains a relational field whos comodel is `res.users`, with a *pathological* domain of `not ilike` `'some_string'`, the ORM will call a `_name_search` on `res.users` with no limit to resolve the leaf when calling `_where_calc`. The current implementation in the `web` module overrides the `_name_search` to implement a spec to propose the current user as a first suggestion, but to do that it first execute the query (the list conversion), and then manipulates the list of ids to insert the current user first. (1c2ce8c213754aa47c51d68b6a8acd4770588864) On large databases with many `res.users`, where the condition matches all users besides 1, this is a probably Seq.Scan on the `res_users` table. Then this gigantic list of `ids` will be injected by the ORM into the main query to satisfy the original domain. This incurs not only bandwidth costs, but also usually leads to bad plans, ending up most likely into a Seq.Scan on the original table. The worse of it, in the case of a `web_search_read`, there is a `search_count`, so this whole fiasco is repeated once more. The nail in the coffin, is that the result isn't even needed, when resolving a comodel's `_name_search`, we care about the subset, the internal order is irrelevant. ## Solution The ORM calls the `_name_search` without a limit, while in general the `name_search` is called with a limit from the front-end, therefor we can use it as a discriminant -> If no limit, don't suggest `uid` first. ## Affected versions saas-16.3 -> master (saas-17.2) ## Reference task-3610657 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152488