Odoo 19 accélère vos pivots avec GROUPING SETS, read_group déprécié

Un tableau croisé dynamique dans Odoo traîne depuis longtemps un défaut discret. Chaque fois qu'un utilisateur déplie une ligne ou une colonne, le client web envoie une requête supplémentaire au serveur. Sur un pivot un peu chargé, ces appels s'empilent pour afficher un seul écran. Odoo 19 s'attaque à ce point en exploitant une fonctionnalité présente dans PostgreSQL depuis des années mais restée en marge de l'ORM : les GROUPING SETS¹.

Un pivot, une seule requête

La logique historique était simple à décrire et coûteuse à exécuter. Pour un pivot croisant deux niveaux de lignes et deux niveaux de colonnes, Odoo lançait un appel formatted_read_group par combinaison de regroupement. Chaque appel repartait vers le serveur, refaisait une requête SQL, puis revenait. Le client additionnait ensuite les résultats.

La pull request #194413, intitulée « [IMP] core: add grouping set support for pivot view » et signée ryv-odoo, remplace cette cascade par une seule requête. Elle introduit deux méthodes : _read_grouping_sets côté serveur et formatted_read_grouping_sets pour le client web². Comme les différents regroupements d'un même pivot partagent leurs arguments, à l'exception du groupby, et n'utilisent ni limit ni offset, ils se prêtent bien à la clause GROUPING SETS de PostgreSQL. Le moteur calcule alors plusieurs agrégations en un seul passage.

Les mesures publiées avec la contribution donnent un ordre de grandeur concret.

Ces chiffres viennent des benchmarks de la contribution elle-même, pas d'un test indépendant de notre part. Ils décrivent des situations précises et ne se transposent pas mécaniquement à chaque installation. La direction reste néanmoins nette : moins d'allers-retours réseau, donc un rendu plus court sur les pivots et les tableaux de bord qui les embarquent. La contribution a été fusionnée dans la branche master le 12 juillet 2025, celle qui a donné la version 19.

Le point intéressant pour un intégrateur, c'est que ce gain arrive sans code à écrire. Un pivot standard, ou un pivot custom qui repose sur le mécanisme natif, en profite directement après migration vers la 19.

read_group cède la place

Le second changement touche l'API elle-même, et il demande, lui, une relecture de vos modules. La méthode read_group, utilisée depuis des années pour agréger des données, est dépréciée dans Odoo 19. Deux méthodes prennent le relais selon l'usage.

Pour du code serveur, la méthode recommandée devient _read_group, dont la signature a été revue dans la pull request #110737, « Read_group: A New Hope ». Elle retourne des données brutes, sous forme de tuples, et se rapproche de la façon dont l'ORM travaille en interne. Pour un résultat mis en forme, proche de l'ancien retour en liste de dictionnaires, la méthode publique devient formatted_read_group. Cette dernière a été conçue pour corriger certains comportements déroutants de read_group et pour suivre le même ordre d'arguments que _read_group, ce qui rend la transition plus lisible.

La distinction se résume assez bien. Si votre module appelle read_group pour un calcul interne, visez _read_group. Si vous avez besoin d'un retour formaté, par exemple pour alimenter une réponse d'API ou un rendu, passez par formatted_read_group.

Ce que ça implique dans vos modules

Le risque principal ne vient pas des nouvelles méthodes, mais de tout le code existant qui surcharge read_group. Beaucoup de modules métier redéfinissent cette méthode pour injecter une ligne calculée, filtrer un regroupement ou ajouter une colonne agrégée. Ces surcharges continueront de fonctionner tant que la compatibilité est maintenue, mais elles s'appuient sur une méthode marquée comme dépréciée. La bonne pratique consiste à repérer chaque def read_group et chaque appel direct dans vos dépôts, puis à décider au cas par cas de la cible.

Un second point mérite attention : les signatures diffèrent. _read_group ne renvoie pas la même structure que l'ancien read_group, et un simple remplacement de nom ne suffira pas. Il faut adapter la lecture du résultat, en particulier là où votre code parcourait des dictionnaires nommés. Prévoyez des tests sur les vues pivot et les rapports agrégés, car ce sont eux qui exercent réellement ce chemin de code.

Pour la partie GROUPING SETS, l'effort est inverse. Vous n'avez rien à porter, mais vous avez tout intérêt à vérifier que vos pivots custom passent bien par le mécanisme natif plutôt que par une pile d'appels maison. Un pivot qui reconstruit ses regroupements à la main ne bénéficiera pas de l'optimisation.

Notre lecture

Ces deux évolutions vont dans le même sens : réduire le nombre de requêtes et clarifier l'API d'agrégation. Le gain sur les pivots est gratuit après migration, ce qui est rare et appréciable. La dépréciation de read_group, en revanche, entre dans la catégorie des changements silencieux : rien ne casse tout de suite, mais la dette s'installe si vous ne traitez pas vos surcharges. Sur un projet en cours de migration vers Odoo 19, nous traitons ce chantier avec les autres dépréciations ORM, dans le même passage de revue de code, plutôt que de le repousser à un correctif ultérieur. C'est le moment où le coût de mise à jour est le plus bas.

Sources

• Odoo 19.0, changelog ORM (support GROUPING SETS pour les vues pivot) : https://www.odoo.com/documentation/19.0/developer/reference/backend/orm/changelog.html
• Pull request odoo/odoo #194413, « [IMP] core: add grouping set support for pivot view » : https://github.com/odoo/odoo/pull/194413
• Pull request odoo/odoo #110737, « Read_group: A New Hope » : https://github.com/odoo/odoo/pull/110737
• Odoo 19.0, référence ORM API (search/read, constraints) : https://www.odoo.com/documentation/19.0/developer/reference/backend/orm.html