Creation BDD - Séparer FWD GeoNature et atlas

[pnx-si]

Creation BDD - Séparer FWD GeoNature et atlas

[gildeluermoz]

Le contenu du schéma atlas (vues matérialisées) repose sur les tables distantes FDW de GeoNature. Si on n'a plus les tables FDW dans les schémas de GeoNature, comment écrire le SQL des vues du schéma atlas ? Pour créer une vue, il faut bien appeler des données contenues dans des tables !

Solution alternative :
Créer une installation pour GeoNature (avec les FDW et les vues matérialisées)

Prévoir une autre installation pour les utilisateurs sans GeoNature avec uniquement un schéma atlas basé sur la création de tables. Dans ce cas, il ne faut pas préfixer les entités du schéma atlas avec vm_observations, vm_taxons, vm_altitudes mais les nommer observations, taxref, altitudes.

Dans un cas, on aura des vues matérialisées, dans l'autre des tables. Si les entités portent le même nom, pour l'application c'est la même chose et les performances devraient être identiques.

[camillemonchicourt]

En effet celui qui n'a pas GeoNature, après l'installation du schema atlas, les vues ne fonctionneront pas et l'application non plus.

L'étape suivante pour celui qui n'a pas GeoNature, c'est d'intégrer ses données dans la BDD dans des tables qu'il se créé (en FWD, en dur, comme il veut) et de mettre à jour les vues matérialisées pour les adapter à la structure de ses BDD sources.

Mais du coup c'est bon comme c'est je pense. Il faut juste séparer les SQL en deux.

[gildeluermoz]

La création de la base se réparti entre les sql dans data et le install_db.sh
Je ne comprends pas bien quel doit être l'état de la base pour l'utilisateur n'utilisant pas GeoNature.

[gildeluermoz]

Je propose de livrer un schéma atlas avec une structure de tables (vides) que l'utilisateur pourra remplir ou transformer en vues à partir de données situées là où il le souhaite. Ceci lui donne la structure attendues par l'application : nom des tables et des champs, typage des champs.

[camillemonchicourt]

Oui oui j'ai vu ça.
Pour le gars qui n'a pas GeoNature, il a juste le schema atlas avec les vues par défaut, qui donc ne fonctionneront pas dans son cas. Il doit intégrer ses données dans des tables comme il le veut et ensuite adapter les vues.

[camillemonchicourt]

OK si tu veux mais ça t'oblige à faire 2 types d'installation du schéma. Si le gars a GeoNature ou si il l'a pas. Et à les maintenir.

C'est plus sympa pour le gars qui n'a pas GeoNature mais c'est pas crucial.

[gildeluermoz]

non, on ne peut pas créer des vues qui ne fonctionnent pas car pas de tables sources. Le SQL sera rejeté. Il faut créer des tables que "le gars" transformera en vue si ça correspond à son organisation.
Ce que je veux dire c'est qu'on ne peut rien mettre en optionnel. On a deux contextes d'utilisation différents et pour ce qui est de la création de la structure de la base, on doit les traiter séparément.

[camillemonchicourt]

Ah OK, je ne savais pas qu'on ne pouvait pas créer une vue si les tables sources n'existent pas !
OK bah quand la structure des vues sera bien validée, en effet on créera un SQL à part qui créé la structure nécessaire à l'atlas mais sous forme de tables.

Le fichier install_db.sh lira un paramètre qui lui indiquera si il doit executer le SQL avec GeoNature ou sans.

[gildeluermoz]

On fait ça. Ok !

::CREATE VIEW atlas.test AS SELECT taxonomie.toto.cd_nom FROM taxonomie.toto
 ERREUR:  la relation « taxonomie.toto » n'existe pas 
 LINE 3:    FROM taxonomie.toto

[camillemonchicourt]

C'est fait.
Dans le settings.ini on déclare si on connecte l'atlas à une BDD GeoNature ou non (https://github.com/PnEcrins/GeoNature-atlas/blob/master/main/configuration/settings.ini.sample#L33) et selon ce paramètre, l'installation est différente. Ce paramètre va notamment faire que les SQL spécifiques à une connexion GeoNature vont être exécutés ou non : https://github.com/PnEcrins/GeoNature-atlas/tree/master/data