Limiter ce module à la structure de BDD et à l'API

camillemonchicourt commented 3 years ago

Actuellement le sous-module de nomenclature créé la BDD, propose une API pour celle-ci, mais inclut aussi la partie contenu des nomenclatures liées au projet GeoNature :

Celle-ci étant spécifique devrait être basculé au niveau de GeoNature, le sous-module Nomenclature restant ainsi générique et pas lié à une thématique ou un usage métier (GeoNature)

bouttier commented 3 years ago

Dans la branch alembic, j’avais créé des migrations paramétrable pour choisir de charger les données ou non :

Ce n’était pas très clair pour moi comment considérer ces données : est-ce des données métier, nécessaire au fonctionnement de l’application, ou est-ce des données facultative / d’exemples ? Ton ticket semble apporter la réponse : il s’agit de données nécessaire à GéoNature, mais ne relevant pas du cœur du module Nomenclature.

Je propose donc (lorsque je continuerai sur la partie Alembic) de créer une migration GeoNature, dépendant du module Nomenclature (afin que le schéma soit préalablement créé), qui s’occupera de charger ces données.

camillemonchicourt commented 3 years ago

Si on devrait intégrer cette partie données dans le cœur de GeoNature et non pas dans le sous-module Nomenclatures qui devrait être que l'API.

bouttier commented 2 years ago

Finalement ça me semble une bonne chose que les données soient ici. Je ne pense pas que qui que ce soit s’amuse à utiliser ce module dans un autre projet pour le remplir avec des nomenclatures non SINP. Ça me semble donc tout-à-fait pertinent de voir ce module comme le « référentiel nomenclatures SINP ».

Rom1deTroyes commented 2 years ago

Je ne pense pas que qui que ce soit s’amuse à utiliser ce module dans un autre projet pour le remplir avec des nomenclatures non SINP.

Pour ce que ça vaut, je travaille actuellement sur des nomenclatures de machines et de processus industriels : un module flask bien documenté permettant de déplier une nomenclature me serait d'une grande aide :-)

Merci pour tout ce code à étudier, c'est super enrichissant <3

mvergez commented 1 year ago

Salut !

Je me permets de relancer un peu le sujet sur les dépendances en base de données de ce module.

En effet, pour GeoCam (application de gestion de camera traps) nous souhaiterions utiliser ce module en mode standalone. J'ai créé une branche pour dockeriser l'application que je contribuerai si j'arrive à tout faire fonctionner mais j'ai quelques soucis :

Dans cette migration : https://github.com/PnX-SI/Nomenclature-api-module/blob/develop/src/pypnnomenclature/migrations/versions/a763fb554ff2_nomenclatures_taxonomie_data.py il y a un depends_on d'une branche de taxonomie ce qui requiert l'installation de tout le schéma taxonomie si je ne me trompe pas. N'ayant besoin que des branches nomenclatures et nomenclatures_inpn_data, alembic cherche quand même à satisfaire cette dépendance. Avez-vous une idée pour l'en empêcher ?
Dans cette migration : https://github.com/PnX-SI/Nomenclature-api-module/blob/develop/src/pypnnomenclature/migrations/versions/6015397d686a_nomenclatures.py, il y a une dépendance à une migration relative au schéma utilisateur que nous ne souhaitons pas non plus installer.

Serait-il donc possible de déplacer les migrations spécifiques aux utilisateurs et taxonomie dans GeoNature directement ? Ou dans leurs dépôts associés (taxhub/usershub) ? Car les schémas taxonomiques ou utilisateurs ne semble pas relever des nomenclature si ? Je peux essayer de m'en occuper mais je voulais d'abord voir avec vous si ça vous semble pertinent.

Merci d'avance pour vos retours !

camillemonchicourt commented 1 year ago

Je reste sur l'idée que ce module ne devrait fournir qu'une coquille vide, et que les nomenclatures SINP devraient être gérées au niveau de GeoNature (@mvergez ça ne ferait pas ton affaire, car si ce sont les nomenclatures SINP dont tu as besoin dans un autre projet, alors il te faudrait GeoNature...). Mais cet outil doit donner une structure pour gérer des nomenclatures, mais pas les nomenclatures elles-mêmes.

On peut garder le compromis de laisser le contenu des nomenclatures SINP dans ce module, mais ça change un peu son rôle et périmètre.

Par contre, en effet, c'est dommage que ce module ait besoin des données de UsersHub et de TaxHub. Par contre, il n'est pas non plus souhaitable que ce module de nomenclature dépende de UsersHub...

Donc pour moi, il faudrait complètement supprimer le lien entre nomenclatures et les organismes de UsersHub (d'autant plus que ce n'est utilisé nul part), mais c'est un chantier pas anodin.

Pour la dépendance de nomenclature avec TaxHub, si on fait le choix de garder le contenu des nomenclatures SINP dans ce module, alors il me semble que la correspondance entre nomenclatures et groupes de taxons doit aussi rester ici, car ce serait bien dommage que TaxHub dépende de ce module nomenclature, alors qu'il n'en a pas l'usage.

Sinon, on fait du lien entre nomenclatures et taxons une branche Alembic à part, optionnelle, comme ça on ne l'impose pas pour ceux qui utilisent ce module. Mais est-ce possible ?

bouttier commented 1 year ago

@mvergez

Non il n’y a pas de moyen d’empêcher Alembic de chercher cette dépendance. La solution est donc d’installer taxhub dans le venv, même s’il n’est pas du tout utilisé. À noter qu’il est prévu de supprimer la branche nomenclature_taxonomie_data pour gérer l’insertion des données avec une commande (comme le référentiel taxref) mais il restera dans tous les cas la branche nomenclature_taxonomie qui dépend du schéma de taxonomie. Je pense que cette dépendance est souhaitable et n’envisage d’autre solution à ce stade (une solution pourrait être de découper ce module en 2 pour séparer la partie taxo, mais pas envie de gérer un nouveau repo juste pour ne pas installer taxhub dans le venv – en revanche taxhub pourrait être coupé en deux pour séparer l’application de la partie base, un peu comme usershub & usershub-auth-module).
La dépendance à UsersHub est absolument nécessaire car il y a une FK vers les organismes. Cependant, c’est pour une fonctionnalité non aboutie et décriée qui est de pouvoir avoir des nomenclatures par défaut qui dépend de l’organisme ! Je serai partisan de supprimer cette fonctionnalité, et donc cette FK, et donc la dépendance à usersHub. Mais il y a également quelques fonctions SQL à reprendre pour cela, tout en se méfiant du fait qu’elles sont utilisé par GeoNature.

@camillemonchicourt

C’est bien une branche indépendante, mais le simple fait de mentionner des révisions de taxhub rend nécessaire d’avoir taxhub dans le venv.
Faire un module générique de gestion des nomenclatures mais sans les outils pour intégrer les nomenclatures SINP me semble assez superflu tant la structuration même des tables suit la logique SINP ! Puis fournir la possibilité d’intégrer les données SINP n’engage pas à les intégrer.

mvergez commented 1 year ago

Merci beaucoup pour vos retours !

C'est bien ce que je me disais pour alembic, impossible de l'en empêcher même si on utilise pas la branche...
Oui complètement d'accord avec toi pour ne pas créer encore un autre repo juste pour ça.
Merci pour ces précisions sur cette FK vers les organismes. Oui faut voir les impacts que ça peut avoir effectivement...

Mais alors pourquoi ne pas déplacer ces migrations dans GeoNature directement ? Car finalement ces migrations font le lien entre la taxonomie et les nomenclatures et entre les organismes et les nomenclature, ce qui est un peu le job de GeoNature non ? Ou alors c'est la responsabilité de Taxhub pour la partie taxo : de faire le lien entre sa taxonomie et les nomenclatures, idem pour usershub. Mais ce n'est sûrement pas si simple...

Je suis d'accord avec @bouttier sur le fait que ce module est un module de nomenclatures SINP car construit autour du modèle de données SINP. Trop de généricité ne servirait pas à grand chose à mon avis.

bouttier commented 1 year ago

Ça devient un sacré méli-mélo si les nomenclatures sont dans un schéma et répo dédié, mais que c’est geonature qui vient rajouter dans ce schéma la gestion des nomenclatures par défaut … La partie taxo pourrait potentiellement est migré vers GeoNature car c’est du spécifique GN (à moins que le SINP intègre ce genre de lien dans le futur).

DonovanMaillard commented 1 year ago

je sais que ça intéressait au niveau national en lien avec les missions TaxRef, j'en avais discuté avec Pascal Dupont. mais je n'ai pas connaissance d'une intégration quelconque pour le moment ni planifiée :) A noter que ce travail là n'est même pas totalement terminé du coté de GeoNature, certains groupes spécifiques ne sont pas traités, et les dernières nomenclatures créées ne le sont pas non plus à ma connaissance (comportement notamment?)

mvergez commented 1 year ago

Merci @DonovanMaillard pour les infos !

Ça devient un sacré méli-mélo si les nomenclatures sont dans un schéma et répo dédié, mais que c’est geonature qui vient rajouter dans ce schéma la gestion des nomenclatures par défaut …

Je n'ai pas trop compris ce que tu veux dire par là...

La partie taxo pourrait potentiellement est migré vers GeoNature car c’est du spécifique GN (à moins que le SINP intègre ce genre de lien dans le futur).

C'est le point que je voulais mettre en avant : laisser GeoNature gérer la partie Taxo. Mais aussi la partie organisme pour les mêmes raisons (si la FK est conservée). Car je trouve dommage de devoir intégrer la notion d'organismes et d'application (t_applications) juste pour ce module de nomenclatures.

bouttier commented 1 year ago

Comme je le disais, la notion d’organisme a été introduite pour les nomenclatures par défaut. Déplacer la notion d’organisme vers GeoNature, ça veut dire déplacer les nomenclatures par défaut vers GeoNature, or il me semble souhaitable que cette fonctionnalité reste avec les nomenclatures.

camillemonchicourt commented 1 year ago

Oui il faut plutôt supprimer les notions d'organisme et d'applications qui n'ont pas vraiment de sens, ni d'usage dans GeoNature.

C'étaient des idées, mais non mises en oeuvre, donc pas utiles, et qui ne font que compliquer le truc.

PnX-SI / Nomenclature-api-module

Limiter ce module à la structure de BDD et à l'API #38