You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
La gestion du modèle de monitoring est assurée par deux entités GeoNature et Monitoring. Cette séparation un peu arbitraire pose problème dans le contexte de la refonte actuelle de monitoring notamment le passage de id_nomenclature_type_site en valeur multiple (création de la table cor_type_site +… dans le module monitoring).
La version multiprotocole ajoute les tables suivantes qui devrait être dans le coeur de GeoNature :
cor_module_type
bib_type_site
cor_type_site
ce qui entraine par conséquence la suppression de id_nomenclature_type_site de la table t_base_site hors le modèle t_base_site est dans le coeur de geonature.
Pour être plus cohérent il faudrait peu être repenser les migrations et la gestion des modèles pour les déporter au maximum dans le coeur de GeoNature (S1) voir aller vers la suppression des tables de complément et leur transfert dans un champ additional_data (S2).
Oui comme évoqué dans d'autres issues, je suis favorable à basculer le maximum (tout ?) de la BDD et de l'API dans GeoNature et de supprimer les tables de compléments.
A réaliser au niveau de GeoNature, même si cela peut poser des soucis car la table
cor_type_site
est créée au niveau du module monitoring.The text was updated successfully, but these errors were encountered: