Réduire la dépendance aux structures des tables de stockage des modèles

Concerne notamment les données importées via plume.pg.queries.query_get_categories, soit les catégories associées à un modèle et tout leur paramétrage, ainsi que plume.pg.queries.query_list_template (tous les modèles et leur paramétrage), plume.pg.queries.query_template_tabs (les onglets d'un modèle et leur paramétrage)... Le principe serait de ne plus figer dans Plume la structure des données renvoyées par ces requêtes, afin de limiter les modifications à réaliser à chaque fois qu'un paramètre de configuration est ajouté. Aujourd'hui, cette structure est souvent définie non seulement dans le constructeur de requête de plume.pg.queries, mais aussi dans la fonction qui désérialise le résultat - la fonction d'initialisation de la classe plume.pg.template.TemplateDict, par exemple.

Les requêtes d'import renverraient un dictionnaire JSON dont chaque clé correspond à un champ, construit avec une requête telle que :

SELECT to_json(meta_template_categories_full.*)
    FROM z_plume.meta_template_categories_full
    WHERE tpl_label = %s

Ce fonctionnement est parfaitement cohérent avec la logique de non exhaustivité des modèles, qui veut que Plume revienne au schéma des métadonnées communes pour tout ce qui n'est pas configuré par le modèle.

Cela permettrait aussi de retrouver un fichier template.json plus lisible, où les noms des champs apparaissent.

Réciproquement, la fonction admin.plume_pg._table_from_shape ne devrait pas avoir à connaître exactement la structure de la table. Il pourrait par exemple être judicieux de récupérer en base les noms des champs, puis d'aller chercher les informations disponibles pour chacun dans categories, sans que cela n'empêche de prévoir des traitements spécifiques pour quelques champs particuliers.

MTES-MCT / metadata-postgresql

Réduire la dépendance aux structures des tables de stockage des modèles #118