Development #54242
chargement de tous les formdata lors de l'enregistrement d'un workflow
0%
Description
Vu sur une manipulation d'un workflow, je fais workflow.store() et ça prend des tonnes de temps et je vois la mémoire totalement chargée.
À inspecter un peu c'est lors de rebuild_security, je me dis qu'y faire
@classmethod
def rebuild_security(cls):
- formdatas = cls.select(order_by='id')
+ formdatas = cls.select_iterator(order_by='id')
conn, cur = get_connection_and_cursor()
for formdata in formdatas:
aiderait.
Mais non, toute la conso se fait déjà sur :
conn, cur = get_connection_and_cursor()
cur.execute(sql_statement, parameters)
Fichiers
Révisions associées
sql: use a server cursor to iterate over rows (#54242)
Historique
Mis à jour par Frédéric Péters il y a presque 3 ans
- Fichier 0001-sql-use-a-server-cursor-to-iterate-over-formdatas-54.patch 0001-sql-use-a-server-cursor-to-iterate-over-formdatas-54.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Utilisation d'un curseur côté serveur.
Mis à jour par Frédéric Péters il y a presque 3 ans
- Statut changé de Solution proposée à En cours
(il y a à vérifier davantage, à tester il y a des "named cursor isn't valid anymore" qui apparaissent).
Mis à jour par Frédéric Péters il y a presque 3 ans
- Fichier 0001-sql-use-a-server-cursor-to-iterate-over-rows-54242.patch 0001-sql-use-a-server-cursor-to-iterate-over-rows-54242.patch ajouté
- Statut changé de En cours à Solution proposée
Voilà, bonne chose les tests échouaient aussi; cette version utilise un curseur côté serveur pour tout sauf l'itération sur la vue wcs_all_forms.
Mis à jour par Nicolas Roche il y a presque 3 ans
- Statut changé de Solution proposée à Solution validée
Relu.
(si j'ai bien compris, on utilise un curseur côté serveur pour fragmenter les données envoyées au client, et plus particulièrement on utilise un curseur nommés pour pouvoir itérer dessus.)
https://www.psycopg.org/docs/usage.html#server-side-cursors
Je me demande juste si c'est voulu ou non d'avoir inversé l'ordre commit puis close (comme c'est fait ailleurs).
Mis à jour par Frédéric Péters il y a presque 3 ans
Je me demande juste si c'est voulu ou non d'avoir inversé l'ordre commit puis close (comme c'est fait ailleurs).
Oui les curseurs sont invalidés au commit sur la connexion. (ça pourrait sans doute être inversé partout sans conséquence).
Mis à jour par Frédéric Péters il y a presque 3 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 471c4a32dc47db66b3cb81e325eef1cc14a06da7
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Mon May 24 22:04:32 2021 +0200
sql: use a server cursor to iterate over rows (#54242)
commit 374a282488889d63f7d05fe3bc7295d8dff2083e
Author: Frédéric Péters <fpeters@entrouvert.com>
Date: Tue May 25 08:15:33 2021 +0200
sql: remove legacy postgresql version check (#54242)
Mis à jour par Frédéric Péters il y a presque 3 ans
- Statut changé de Résolu (à déployer) à Solution déployée
sql: remove legacy postgresql version check (#54242)