Development #34179
concurrence de migrations (le migrate user_label ne fonctionne pas)
0%
Description
Après mise à jour des recettes, sql_level est bien passé à 32 mais les tables/vues n'ont pas gagné de colonne user_label.
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a presque 5 ans
(mais la migration qui suit, qui ajoute la colonne last_update_time aux sessions, est bien passée)
Mis à jour par Frédéric Péters il y a presque 5 ans
Ça semble n'avoir concerné que le SaaS de recette, sur des installations externes ça me semble tout à fait ok.
Mis à jour par Thomas Noël il y a presque 5 ans
- pour l'ajout dans les formdata, on passe par :
set_reindex('formdata', 'needed', conn=conn, cur=cur) - et pour les vues, on fait :
migrate_views(conn, cur)
Mais le set_reindex ne fait rien, en réalité. Il va juste lancer la migration "plus tard", au prochain cron.
Et donc, les vues ne sont pas ok. Sans doute que tripoter une formulaire va suffire à tout recréer.
Mis à jour par Frédéric Péters il y a presque 5 ans
Mais le set_reindex ne fait rien, en réalité. Il va juste lancer la migration "plus tard", au prochain cron.
Je ne vois pas le rapport (le set_reindex est pour passer sur les formdata, ce qui n'est pas nécessaire ici); je creuserai davantage demain, en simulant les migrations dans les tests.
Mis à jour par Thomas Noël il y a presque 5 ans
Frédéric Péters a écrit :
Mais le set_reindex ne fait rien, en réalité. Il va juste lancer la migration "plus tard", au prochain cron.
Je ne vois pas le rapport (le set_reindex est pour passer sur les formdata, ce qui n'est pas nécessaire ici); je creuserai davantage demain, en simulant les migrations dans les tests.
Effectivement ; j'ai été enduit d'erreur par le commentaire
...
# 31: add user_label to formdata
set_reindex('formdata', 'needed', conn=conn, cur=cur)
Mis à jour par Frédéric Péters il y a presque 5 ans
- Statut changé de Nouveau à En cours
Sur les prods, sauf s'il y a eu manipulation manuelle, ça m'a l'air d'avoir fonctionné sans soucis (j'ai regardé le saas, rochefort et sictiam).
Mis à jour par Frédéric Péters il y a presque 5 ans
- Sujet changé de le migrate user_label ne fonctionne pas à concurrence de migrations (le migrate user_label ne fonctionne pas)
Ça n'apparait que sur des déploiements redondants, l'idée ici c'est que :
- sur node1 la migration est jouée,
- pendant ce temps, sur node2, qui continue sa vie, une requête se trouve appeler do_formdef_tables, qui voit que le champ user_label existe "en trop", décide du coup d'appeler le redo_views,
- bardaf, c'est l'embardée.
Mis à jour par Thomas Noël il y a presque 5 ans
Frédéric Péters a écrit :
- bardaf, c'est l'embardée.
Effectivement, analyse convaincante. Du coup, ça ne serait arrivé que sur user_label parce qu'on n'a pas ajouté de champ de ce type depuis la naissance des systèmes redondants ?
Mis à jour par Frédéric Péters il y a presque 5 ans
Yep, le précédent,
ce94b90179 (Thomas NOEL 2018-05-01 12:22:19 +0200 2275) # 27: add last_jump_datetime in evolutions tables
Mis à jour par Frédéric Péters il y a plus de 2 ans
- Statut changé de En cours à Fermé
pendant ce temps, sur node2, qui continue sa vie, une requête se trouve appeler do_formdef_tables, qui voit que le champ user_label existe "en trop", décide du coup d'appeler le redo_views,
Ça ne peut (presque) plus avoir lieu dans la mesure où les modifications de schéma sont limitées au .store() du formdef, plus au simple accès à formdef.data_class(). (#57118).
tests: add check for user_label migration (#34179)