[Général] Stocker les versions des modules et des applications en bdd

[lpofredc]

GeoNature étant db first Je trouverai intéressant de stocker en bdd les versions des applications et modules.

• Pour GeoNature, dans la table gn_commons.t_module par exemple.
• Pour TaxHub et UsersHub, dans leurs schémas spécifiques (table spécifique <taxonomie/utilisateurs>.version?).

Plusieurs avantages à cela selon moi.

• Si on a besoin de restaurer une ancienne et lointaine sauvegarde (ex. on se rend compte tardivement d'une grosse bavure ;). On peut retracer les modifications de structure de bdd pour faciliter la restauration.
• On peut faire une vérification de la version avant de lancer un script de MaJ de la bdd (on lance si la version précédente et la bonne, sinon on abandonne. DO BEGIN IF version = "x.x.x" THEN ... ), a voir si toujours pertinent avec alembic (cf. #880).
• Ça permet d'y voir plus clair quand on administre plusieurs instances GeoNature, qu'on récupère des dumps transmis par un tiers, etc.

[bouttier]

Effectivement connaître la version du schéma de sa base de données est très utile, et c’est très exactement ce que fait Alembic afin de pouvoir savoir quelles sont les migrations à appliquer. De mon point de vue ce problème sera donc résolu avec Alembic.

Pour être plus précis sur la manière dont Alembic stock cette information, celui-ci a une table public.alembic_version contenant une seule colonne alembic_version. Il y stock le ou les numéro de version des migrations appliquées. À noter que les migrations installées en tant que dépendances ou ancêtres de nouvelles révisions sont considérées comme nécessairement installées et donc ne figure pas dans la table.

[camillemonchicourt]

OK mais ce que je vois pas clairement c'est que les versions des migrations appliquées ne sont pas reliés aux versions du module ? Du coup connaitre les migrations passées n'indique pas la version du module à laquelle on est ou était ?

[bouttier]

Effectivement on a l’info de la version du schéma de DB, pas de la version du module. Mais à mon avis c’est la version du schéma qui nous intéresse lorsque l’on souhaite restaurer un dump. Il reste possible de relier une version de schéma à une version d’un module en regardant avec quelle version est apparu la révision du schéma. C’est une info qu’il est sans doute bien de faire figurer dans les notes de versions, et pourquoi pas même un tableau dans la doc de correspondance versions schéma / module.

[lpofredc]

Selon moi, ce sont deux informations complémentaires. Mon propos initial était bien de disposer facilement des versions des applications installées. Le volet évolutions de la bdd (migrations) était un exemple de ce que cela pouvait apporter mais ce n'est pas tout. Cela permet aussi d'échanger sur des problèmes techniques en disposant rapidement de toutes les versions installées sur l'instance en question (vue de synthèse des versions?).

Autre exemple, je viens par exemple de créer sur GeoNature-citizen un trigger pour peupler automatiquement GeoNature. Si la bdd évolue, avec les versions archivées en bdd (ce qui a été récemment le cas avec les champs méthode d'observation/technique d'observation,), on peut imaginer créer une procédure avec un IF qui créera la fonction de trigger adaptée à l'instance courante.

[bouttier]

Avoir une page (ou au moins une commande) listant la version de GéoNature et de tous ses modules me semble une très bonne idée !

Après personnellement je suis peu favorable à enregistrer la version du code en db, en raison du risque d’incohérence entre la version en db et la version réelle du code qui tourne, ainsi qu’en raison de la nécessité lorsque l’on fait évoluer le code de bien mettre à jour la db. Aussi, on se prive de la possibilité d’utiliser des outils tel que setuptools_scm capable d’auto-détecter la version via git (permettant de savoir également quand on est sur un commit intermédiaire et non une release).

Je ne suis pas sûr d’avoir bien compris le besoin que tu décris pour GeoNature-citizen, mais il me semble lié à un problème de version de db et non de code, non ?