alhyss
commented
2 years ago @PascalAstruc Comme si on importait d'office les modèles pré-configurés avec SELECT * FROM z_plume.meta_import_sample_template() ; ? La finalité est-elle d'avoir des données dans les tables créées par l'extension PlumePg et/ou d'avoir des modèles disponibles dans QGIS quand on a installé l'extension PlumePg sur la base sans pour autant avoir (encore) créé ou importé de modèles ?
Pour le deuxième aspect, une option serait de continuer à proposer des modèles pré-configurés générés à partir d'un fichier stocké en local côté plugin QGIS. On le fait quand PlumePg n'est pas installée sur la base, on pourrait le faire quand elle est installée mais ne définit aucun modèle. Nous étions partis du principe que si l'ADL déployait PlumePg sur une base, il avait certainement l'intention de créer des modèles ou de personnaliser les modèles pré-configurés, mais ça ne poserait pas de problème de changer ça.
Pour ce qui serait de peupler les tables... En fait si les modèles pré-configurés ne sont pas installés par défaut et qu'il faut pour ça exécuter la fonction z_plume.meta_import_sample_template(text), c'est notamment parce ça simplifie grandement les choses pour les restaurations. Celles-ci procèdent en deux temps :
- D'abord elles exécutent le script d'installation de l'extension - le fichier de sauvegarde contient une commande
CREATE EXTENSION plume_pg, en gros. - Puis elles restaurent le contenu des tables, afin que tout le travail fait par l'ADL sur ses modèles ne soit pas perdu.
Si la première étape importe les modèles pré-configurés, que l'ADL aura peut-être choisi de ne pas utiliser, dont il a pu changer le nom, les conditions d'activation, les catégories associées, le paramétrage des catégories, etc., puis que la seconde étape tente d'importer les modèles sous leur forme actuelle, on arrive dans un joyeux sac de nœuds à base de lignes en double, de lignes en trop...
Le seul cas que j'ai osé traiter est celui des catégories de métadonnées communes, qui sont effectivement importées à l'installation dans la table meta_categorie (ou plus précisément sa partition meta_shared_categorie), parce que je suis partie du principe que l'ADL n'avait pas de raison de supprimer des catégories communes. Il a le droit de ne pas les utiliser pour ses modèles bien sûr, mais j'ai considéré qu'il n'était pas gênant de recréer des valeurs qu'il aurait sciemment supprimées. Impossible de tenir le même raisonnement pour les autres tables. Accessoirement, ça a nécessité de mettre en place un déclencheur sur la table - fonction z_plume.meta_shared_categorie_before_insert() - pour aller supprimer les lignes créées à l'étape 1 qui ont la même clé primaire que celles créées à l'étape 2, afin que les INSERT de l'étape 2 n'échouent pas.
Bref, je n'ai pas encore trouvé de meilleure approche que de demander à l'ADL d'importer lui-même les modèles pré-configurés qui l'intéressent...
PascalAstruc
Dans l'installation serait il possible de rajouter un petit jeu de donnée avec métadonnées de base (juste pour avoir quelque chose d'actif au démarrage)