Visibilité depuis la synthèse de champs spécifiques à un protocole

[sig-pnrnm]

Suite à cet échange sur le module d'importation, en poursuivant la réflexion, je me dis que le cas des "champs spécifiques" dépasse le cadre du module d'importation.

C'est plutôt en lien avec la définition de la "synthèse", et donc au cœur du fonctionnement de GeoNature.

Les champs retenus pour la synthèse sont par définition limités, et une perte d'infos et donc acceptée lors du passage entre le module source et la synthèse.

Or, dans certains cas (et en particulier pour le module validation par exemple), avoir accès à ces "infos perdues" est utile.

Trouver un mécanisme qui permette, depuis la synthèse, de consulter les autres champs de la source, sans avoir à modifier la structure de la synthèse à chaque nouvelle source, me semblerait donc pertinent.

Exemple :

Sans être développeur (et donc, vous aurez sans-doute d'autres solutions techniques), il me semble qu'un champ autres_infos de type hstore permettrait d'accéder à ces infos de manière assez simple.

[DonovanMaillard]

si c'est uniquement un besoin de la validation, c'est peut être à gérer au niveau de la validation pour aller lire directement la source et pas la synthèse pour ces champs additionnels? Je trouve (pour ma part, c'est un avis perso) que ca va un peu à l'encontre du principe de la synthèse. On y ré-intègre des champs qui sont spécifiques à tel ou tel protocole et qu'on ne pourra pas analyser "en masse" sur l'ensemble de ses données...

[sig-pnrnm]

si c'est uniquement un besoin de la validation

Non, ce n'est pas uniquement lié à la validation. C'est plus une logique de ne pas dénaturer la donnée source, quand elle est consultée depuis la synthèse. Ces "infos perdues" peuvent en effet avoir une importance capitale pour la nature de la donnée (et donc la "dénaturer" si pas visible).

On y ré-intègre des champs qui sont spécifiques à tel ou tel protocole

Justement non : un seul nouveau champ serait ajouté en synthèse (autres_infos) D'ailleurs, je ne dis pas forcément qu'il faut stocker ces infos dans la synthèse. Mais en tout cas, permettre de les consulter.

[gildeluermoz]

Je regarderai ta piste des champs de type hstore. L'idée est à creuser mais c'est à la fois intérressant et discutable pour les raisons avancées par Donovan. Ca rejoint en partie la notion de champ additionnels du standard SINP Les stocker pourquoi pas mais c'est de la redondance potentiellement lourde (à creuser) A creuser aussi la manière de les lire en interface ou dans des exports car si on fait ça, fait que ça soit utilisable.

[sig-pnrnm]

Sans les stocker, pour ne pas générer de redondance, l'idée pourrait être de gérer un lien générique vers la donnée source complète, dans son protocole. (dans le cas du module d'importation, vers la ligne complète de la table de la donnée importée)

Sinon, pour ce qui est de la consultation en interface, vous verrez dans la doc de ce type de champs qu'il y a énormément de possibilités en SQL très basique. Pour info, c'est la manière dont sont gérés le fait qu'il existe des centaines (milliers) de tags dans la base OpenStreetMap (par exemple par Osm2Pgsql).

[camillemonchicourt]

Il y a déjà un lien entre la donnée source et la donnée dans la synthèse. C'est ce qui permet de retourner directement à la donnée source dans son module depuis la synthèse.

Si il faut gérer des données en plus dans la synthèse, on privilégiera la piste des champs additionnels prévus dans le standard occurrence de taxons

[camillemonchicourt]

Et pour les champs additionnels de la synthèse, après avoir testé la solution sur le module d'inscription et sur le module générique de suivi (gn_monitoring) on s'orienterait plutôt vers des champs au format jsonb.

Voir leur usage sur: https://www.compose.com/articles/faster-operations-with-the-jsonb-data-type-in-postgresql/ Ou encore cette très bonne présentation de @obartunov sur Jsonpath et NoSQL dans PostgreSQL : http://filemirror.s3.amazonaws.com/jsonpath-pgday.it-2019.pdf

Sinon il y a toujours la possibilité de faire une table dédiée (gn_synthese.synthese_extra_fields avec 3 colonnes id_synthese, nom_champ, valeur_champ) comme proposée par @amandine-sahl ici : https://github.com/PnX-SI/gn_module_import/issues/6#issuecomment-483665752