Development #57118
faire les modifications de schéma à la sauvegarde de formdef/etc. plutôt qu'au moment du data_class()
0%
Description
Il n'y a pas vraiment de choix délibéré de faire ainsi, c'était sans doute juste plus facile de faire ça à la volée plutôt qu'avoir au moment d'enregistrer un workflow de parcourir les formdefs associés. (c'est la seule raison un peu pertinente que je vois là).
Le problème avec cette approche c'est que la modification de schéma peut être jouée un peu n'importe quand, genre sur le premier usager qui va sur la démarche, ou sur le premier rafraichissement d'un tableau de traitement. Cette multiplication des occasions rend un peu trop possible d'avoir deux tentatives de schéma exécutées en même temps.
Fichiers
Demandes liées
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Lié à Development #57017: Locker quelque chose pendant les modifications de schéma ajouté
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Fichier 0001-general-directly-apply-formdef-carddef-schema-change.patch 0001-general-directly-apply-formdef-carddef-schema-change.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
Voilà, assez simple, il y avait déjà presque le nécessaire lors de l'enregistrement de workflow.
La partie "object_only" est là pour raccourcir le moment initial qui faisait formdef.store() -> do_formdef_table() -> get_formdef_table_name() -> formdef.store() (et que ce dernier ne reparte pas dans l'SQL etc.).
Au niveau des tests il y a des ajouts de FormDef.wipe(), sans eux on se trouve par endroit à avoir déjà un formdef avec le même url_name et en créer un nouveau avec ce même url_name fait que celui-ci a l'url_name transformé (en url_name-INDEX) et cette modification amène un .store() supplémentaire qui amène un moment une requête SQL vers une table avec le mauvais nom.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Statut changé de Solution proposée à Information nécessaire
Je vois tout de même un défaut à ce nouvel ordre des choses: avec le code précédent à chaque appel à data_class() on retentait de corriger le schéma, même si ce n'était pas très performant ça finissait par corriger d'éventuelles incohérences tout seul. Maintenant il faudra une action manuelle produisant un FormDef.store() avant que l'état du schéma ne redevienne cohérent avec le FormDef (c'est peut-être pour ça que tu as décide de le faire à cet endroit initialement).
C'est peut-être suffisamment rare pour être ignoré; mais ça je ne sais pas.
C'est je pense d'ailleurs ce qui s'est passé sur le ticket CD06 à l'origine du ticket sur les verrous car personne n'a rien fait, mais ça a mis visiblement plus de 20 minutes à se corriger quand même, et je n'ai aucune idée de pourquoi ce fut si long.
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Information nécessaire à Solution proposée
ticket CD06 à l'origine du ticket sur les verrous
Le ticket #57017 est uniquement lié à un ticket à Toulouse, pas CD06.
~~
Je trouve bien plus clair et fiable etc. d'avoir les modifications au schéma de données au moment de l'ajout/suppression de champs, plutôt que "à un moment plus tard on verra bien quand on sera appelé".
Si jamais on se trouve avec des modifications de schémas qui ne correspondent pas à ajout/suppression de champs (formulaire ou données de traitement), et qu'on n'arrive pas à en trouver l'origine (...), alors peut-être on verra pour taper un cron qui fait des do_formdef_tables (mais je ne pense pas qu'on arrive à ça).
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
- Statut changé de Solution proposée à Solution validée
Le ticket #57017 est uniquement lié à un ticket à Toulouse, pas CD06.
Oui je me suis mélangé les pinceaux.
Ok.
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit d38908864fa78fa0f019bfa6def769bb5a691a56 Author: Frédéric Péters <fpeters@entrouvert.com> Date: Mon Sep 20 18:12:37 2021 +0200 general: directly apply formdef/carddef schema changes (#57118)
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de Résolu (à déployer) à Solution déployée
general: directly apply formdef/carddef schema changes (#57118)