Tuesday, September 2, 2025
2 changes · 18.0
Enhancements to existing features
Website module upgrades now process large page data in smaller batches instead of loading everything at once. This reduces memory usage and helps prevent upgrade failures that could block access to a database.
Original PR description
### Issue A user cannot access their database (Bad Gateway) after trying to upgrade a module. ### Analysis The root cause is the out of memory error, stemming from the SQL query fetching all `arch_db` and then fetching them with `fetchall`. ### Solution This commit optimizes the loading of module terms in the `ir_module_module` model by iterating over the rows per chunks. This change reduces the memory footprint, which is crucial when dealing with heavy `arch_db` in the `ir_ui_view` table. We also filter out `if not generic_arch_db` directly in the SQL query instead of on the Python side. After applying this patch, there is no more `MemoryError` and the user can access their database. ### References opw-5014922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223439
Resolved issues and error corrections
The Secure Entries wizard now uses far less memory and loads much faster when many accounting entries are waiting to be secured. This prevents the wizard from crashing on large databases and helps accounting teams complete compliance-related entry security work without delays.
Original PR description
Description ----------- On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be…
Description
-----------
On a database where the user doesn't Secure their accounting entries regularly, it's possible over a long period to accumulate a lot of pending invoices that needs to be hashed.
This can lead to the processing of a large number of moves when opening the Secure Entries wizard, more specifically:
```
-> `_compute_warnings`
-> `_compute_hash_date`
-> `_compute_max_hash_date`
-> `_get_chains_to_hash`
```
While manipulating this large recordset, the ORM prefetcher will read *all* fields on the model upon the first cache miss, which usually are a lot, and some of them are quite large (label type fields).
This commit refactors the code to avoid any cache miss by fetching only what is necessary. This is achieved by:
- Use of a `_read_group` instead of 2 subsequent `groupby`
- Delegate `max` and `min` lookup to the database
- Explicitly fetch the fields that are going to be read
- Avoid the linear search into the associated statement lines for unreconciled moves
- Introduce a context key `chain_info_warnings` to skip the warnings computation of `_get_chain_info`, as it's unused for the context of `_compute_max_hash_date`.
Benchmark
---------
On a database with over 1.3M `account.move` that are pending hashing, opening the wizard for the Secure Entries took:
| | Before* | After | Improvement |
|--------------|---------|---------|-------------|
| Memory | 6.8 GiB | 700 MiB | 9.9x |
| Query Count | 26.7k | 18.5k | 1.4x |
| Timing SQL | 41.2s | 18s | 2.3x |
| Timing PY | 7.29min | 14s | 31.2x |
| Timing Total | 7.98min | 32s | 15x |
\* - benchmark was taken with unlimited memory, the request takes more than 2 GiB -> OOM killed and never completes
Reference
---------
opw-5014345
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr