Open PascalAstruc opened 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 :
CREATE EXTENSION plume_pg
, en gros.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...
Pour la finalité, c'est en fait les 2, pouvoir dés l'installation disposé d'une "mini version demo" avec un jeu de donnée pour pouvoir visualiser dés le début une fiche de métao donnée test et qui permette à l'adl de pouvoir rapidement se faire une idée du fonctionnement. Pour les modèle il ne me parait pas utile de les implémentés tous d'office, mais un seul jeu de donnée serait suffisants (non modifiable par exemple) à loisir pour l'adl d'en rajouter le cas échéant cela permettrais de peupler le menu déroulant de l'interface. Mais il ne faut pas que cela ne doit pas remetre en cause la logique globale, l'idée étant de faciliter la première prise en main. (sans passer par le sql même si ce n'est pas insurmontable, cela pourrait faire peur à certain).
Pour les modèles de bases, le minimaliste est bien et peut être un basé sur l'export de geoide catalogue (uniquement les champs obligatoires)? Là encore la question de la reprise de l'existant sera surement preignante.
Pour les modèles de bases, le minimaliste est bien et peut être un basé sur l'export de geoide catalogue (uniquement les champs obligatoires)?
Le modèle INSPIRE (cf. issue #16) correspond à peu près à cette demande, même s'il inclut aussi quelques champs qui ne sont pas obligatoires du point de vue d'INSPIRE.
Reste la question des jeux de données de test - ou peut-être plutôt de fiches de métadonnées exemples qui pourraient être chargées via l'import DCAT.
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)