Chaque version majeure d'Odoo fait bouger l'ORM, et la 19 ne fait pas exception. Certaines méthodes que vos modules appellent depuis des années passent en déprécié, et d'autres apparaissent pour réduire le nombre de requêtes envoyées à PostgreSQL. Le tour des changements qui comptent pour un développeur de modules tient en trois temps.
Ce qui est déprécié, et par quoi le remplacer
Rien ne disparaît du jour au lendemain, mais ces appels lèvent des avertissements et finiront par casser. Autant les traiter pendant la migration1.
| Ancien | Remplacement |
|---|---|
name_get() | Lire le champ display_name, calculé par _compute_display_name |
read_group() | _read_group() en interne, formatted_read_group() pour l'API publique |
record._cr, record._context, record._uid | self.env.cr, self.env.context, self.env.uid |
odoo.osv | odoo.models et odoo.fields |
_flush_search() | Le flush passe désormais par execute_query() |
fields_get_keys(), get_xml_id() | Alternatives indiquées dans le changelog officiel |
Le cas le plus courant est name_get. Beaucoup de modules le surchargent pour personnaliser l'affichage d'un enregistrement. En 19, cette logique passe par _compute_display_name, et l'on lit display_name partout ailleurs.
Ce qui accélère vos requêtes
La 19 n'est pas qu'un ménage, elle apporte de vrais gains pour qui écrit du code de recherche1.
Un objet d'enveloppe SQL permet de composer des requêtes de façon plus sûre face aux injections, et l'ORM l'utilise désormais en interne. Si vous écriviez encore du SQL à la main avec des chaînes formatées, c'est l'occasion de basculer dessus.
Deux nouvelles méthodes, search_fetch() et fetch(), combinent la recherche et la lecture en un minimum de requêtes. Là où vous enchaîniez un search puis une lecture de champs, une seule passe suffit, ce qui réduit les allers-retours avec la base.
Vous pouvez aussi choisir le type d'index PostgreSQL posé sur un champ, via sa propriété index. Sur une grande table filtrée souvent sur le même champ, le bon type d'index change tout. S'ajoutent les dates dynamiques dans les domaines et le support des GROUPING SETS pour les vues pivot.
Ce qu'il faut faire concrètement
On peut procéder en quelques gestes, dans l'ordre.
On lance d'abord un grep sur ses propres modules à la recherche des appels dépréciés : name_get, read_group, _cr, _context, _uid, odoo.osv. La liste des occurrences donne le périmètre réel de la migration.
On remplace ensuite au fil de l'eau, en testant module par module. Aucune de ces corrections n'est difficile, mais leur nombre peut surprendre sur une base ancienne.
On profite enfin du passage pour adopter search_fetch sur les chemins critiques, ceux qui tournent à chaque chargement de vue ou dans un cron lourd. Le gain de requêtes se mesure vite.
Notre lecture
Odoo 19 est une version de consolidation côté ORM. Le coût de migration est réel mais mécanique, fait surtout de remplacements ligne à ligne. Le même passage qui corrige les dépréciations ouvre l'accès à des outils plus rapides, ce qui en fait un bon moment pour nettoyer le code de recherche d'un module. On ne migre pas seulement pour rester à jour, on en sort avec des requêtes plus économes. Le grep des appels dépréciés est le bon point de départ, et il prend dix minutes.
Sources
- Odoo, changelog ORM officiel (Odoo 19.0) : https://www.odoo.com/documentation/19.0/developer/reference/backend/orm/changelog.html
- Odoo, notes de version 19.0 : https://www.odoo.com/odoo-19-release-notes
Footnotes
-
Odoo, changelog officiel de l'ORM (Odoo 19.0), Developer > Reference > Server framework > ORM > Changelog. Dépréciations (name_get, read_group, _flush_search, odoo.osv, record._cr/_context/_uid, fields_get_keys, get_xml_id) et nouveautés (objet SQL, nouvelle signature de _read_group, search_fetch et fetch, dates dynamiques dans les domaines, GROUPING SETS pour les vues pivot, type d'index via la propriété index des champs). https://www.odoo.com/documentation/19.0/developer/reference/backend/orm/changelog.html ↩ ↩2