camillemonchicourt
commented
8 months ago Oui il faut peut-être aller au bout de la démarche car là c'est certainement un entre-deux complexe et non utilisé.
Initialement, on avait insisté pour que les schémas métier de Geotrek ne soient pas dans le schéma public mais dans des schémas dédiés pour en faciliter la lecture et l'utilisation en dehors de Geotrek. Mais éventuellement aussi de pouvoir intégrer une BDD Geotrek dans une BDD existante (peut-être conceptuel et non utilisé ni pertinent).
Cela a été mis en place dans la version 0.28.0 de 2014 : https://geotrek.readthedocs.io/en/2.101.4/changelog.html#id296
En lien avec https://github.com/GeotrekCE/Geotrek-admin/issues/1947.
Ce fonctionnement a régulièrement apporté de la complexité au niveau des développements au niveau de l'ORM de Django (nécessite de spécifier "schema.table" à chaque requête, au lieu de seulement "table" ainsi qu'au niveau du search_path de PostgreSQL) donc on a cédé en 2020 pour basculer par défaut toutes les tables dans le schéma public.
Mais en effet, on a gardé un système un peu mixte où il reste possible de modifier ce comportement par défaut en configurant d'autres schémas de stockage des données par module avec le paramètre DATABASE_SCHEMAS (https://github.com/GeotrekCE/Geotrek-admin/blob/master/geotrek/settings/base.py#L54-L77).
Je continue à trouver dommage que toutes les tables, fonctions, triggers spécifiques à Geotrek soient dans le schéma public, mais ce n'est pas vital, donc il est certainement préférable d'aller au bout.
Peut-être en profiter pour supprimer les anciens schémas qui ne sont plus utilisés, mais à vérifier car il me semble qu'il reste des choses dans certains schémas comme ici :
Tout une partie du code de geotrek gère la gestion des schemas SQL
Au vue des dévelopement sur les vues sql et les valeurs par défaut en SQL, je doute que ce soit beaucoup utilisé.
Pourrait-on se permettre de supprimer cette notion ?