-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiples instances / Réplications #789
Comments
Je dirais code dédié via les API. En fait tout ça dépend du besoin et de l'organisation souhaitée (1 base centrale et des filles, des bases réparties sans maître ?, autre ?) |
Ne comprenant pas tout je ne sais pas si c'est en lien mais pour éviter qu'un boulot soit fait en double. On a commencé avec Fred à la lpo le développement de scripts permettant de moissonner données et méta-données dans une instance mère pour alimenter une instance fille (basé sur les api des modules exports et méta-données) Ces développements devraient se pour suivre au cours de l'hiver... Je sais pas si ça vous intéresse ou non pour ce sujet ;) désolé d'avance si ça n'a rien à voir |
Oui, je confirme, c'est prévu pour 2020. L'objectif serait de s'appuyer sur le module d'export pour générer des api permettant le partage entre instances geonature. Voici ce qui est envisagé: Côté fournisseur de données : Ajouter une fonction de journalisation sur la synthèse de GeoNature permettant de suivre l’historique des modifications des données naturalistes de la synthèse (insertion, mise à jour, suppression).
Côté collecteur de données: Côté serveur, un premier téléchargement en mode complet (pour télécharger toutes les données de l’export) puis une mise à jour incrémentale régulière (horaire, quotidienne) ne récupérant que les données ayant subit une modification depuis le dernier export (insertion, modification, suppression). Côté base de données:
|
Je reviens vers vous tous pour avancer sur ce chantier et vous propose un premier jet de réflexion sur ce que pourrait être cet outil, à discuter ensemble. en fin de ticket un schéma récapitulatif... ObjectifL’objectif de cet outils est de permettra le reversement automatique de données entre instances geonature et par api. L’émetteur fournit des données filtrées par API, le collecteur réceptionne les données de l’API émetteur et les intègre en base de données via une interface qui fait le lien entre les deux. Les données à communiquer entre instancesDonnées naturalistes
Les métadonnées
Historique des données
Autres données ?
Ce qui existe aujourd’hui dans GeonatureDonnées naturalistes
Métadonnées
Historique des données La journalisation des modifications sur les données est enregistré dans la table
Les outils actuellement disponiblesModule d’exportgénère des api d’après des vues créées en base de données, l’accès aux api peut être restreint pour des utilisateurs/groupes enregistrés dans usershub ou pubiques. Les API générées disposent de capacités de filtrages (querystring) et de pagination. Module d’importImporte des données tabulaires (csv) via des masques paramétrés (par défaut, synthèse geonature). Interface entre les instancesPas de solutions existantes à ce jour. La LPO Auvergne-Rhône-Alpes utilise une application accomplissant le même type de tâches pour importer et mettre à jour en continue les données des portails VisioNature vers une base de données PostgreSQL (https://framagit.org/lpo/Client_API_VN/) dont le fonctionnement est proche de ce qui est attendu ici. Une partie de l'application pourrait-être utilisée. Le processus envisagéCet outil s’appuierait sur le module d’export et une application à développer qui ferait l’interface entre les deux instances de GeoNature. Côté collecteurCe fonctionnement nécessite l’ajout d’une journalisation sur les tables (
Les étapes réalisées seraient :
Côté interfaceL’interface serait une application Python (sans doute autonome dans un premier temps, possiblement intégrable en module dans un second temps) qui assurera le butinage sur les différentes sources renseignées. Pour chaque source, il faudrait spécifier l’URL du dictionnaire des URL du partage, et les paramètres d’authentification (identifiant, mot de passe). Deux modes seront disponibles :
Côté collecteurLes données sont intégrées dans un schéma spécifique (ex : import_geonature) dans 4 tables correspondant aux 4 types de données, soit au format JSONB plus souple mais plus lourd, soit en colonnes avec en plus une colonne spécifiant la source de la donnée.
Des déclencheurs d’évènements surveillent ces tables pour mettre à jour les tables de GeoNature respectives. Premières questions en suspens
|
Salut Fred, Sans trop rentrer dans le détail dans l'immédiat, penses-tu repartir des premiers travaux qu'on a entamés l'an dernier ou reprendre les choses depuis la base? Je vois que c'est très proche de ce qu'on avait entamé mais tu n'en as pas parlé. De manière générale pour les taxons nouveaux, pour les nomenclatures personnalisées etc, j'aurais tendance à fonctionner avec quelque chose du style "ON CONFLICT DO NOTHING" de manière à ignorer les cas particuliers, qui seraient récupérés ultérieurement (on peut imaginer un rapport d'erreur dans les logs du script pour avoir connaissance de ces cas là coté serveur dans un premier temps). Ca peut aussi concerner des nomenclatures supprimées dans la base collecteur ou autres cas. Coté nomenclature, une pratique prévue consiste à créer des nomenclatures custom mais à les rattacher à des nomenclatures "officielles" via le champs id_broader. Ca permet de créer des nomenclatures filles précises et adaptées pour des besoins internes mais de faciliter la transformation vers le standard en identifiant la nomenclature valide qui correspond. Il peut etre intéressant, quand un cd_nomenclature est customisé, de voir s'il a un broader valide du SINP. Coté métadonnées, il serait intéressant de se baser sur l'API du module métadonnée de la base émetteur. La t_source ne me semble pas pertinente à prendre en compte dans ce fonctionnement en revanche, elle est surtout technique finalement et concerne l'instance en elle-même (table d'origine, champs source de la pk etc), qui ne sert pas si on a pas la donnée source dans la base collecteur. Coté organismes, l'idéal serait en effet, à terme, que chacun puisse avec UsersHub aller importer des organismes qui sont dans le référentiel SINP... mais ça soulève plein de soucis (usershub n'est pas destiné qu'à GeoNature ni qu'au contexte sinp). Sur la manière de mettre à jour des métadonnées, je la verrais comme pour les données avec une mise à jour fréquente. En revanche il n'est peut être pas nécessaire d'historiser toutes les actions : ca représente un volume de données assez faible, on peut peut être prévoir un update complet Peut êtr- avec une fréquence inférieure à celle des données, en dehors des cas où un nouveau jeu de données doit être importé qui se fait d'office ? Sur la priorisation des informations : je pense que selon les cas et les pratiques des uns et des autres, ça peut différer. J'imagine qu'un paramètre dans la configuration du script pourrait permettre à l'utilisateur de choisir son fonctionnement (j'importe les dates de l'émetteur, ou je mets les miennes). Ou alors imaginer un 3eme champs date, pour le rafraichissement de la donnée (indépendant de sa création et sa mise à jour qui sont différents). Je rajoute une question : qui de l'id_digitiser. D'un point de vue technique, il faudrait aussi anticiper, ou au moins documenter, le fait que l'import "full" initial va potentiellement bloquer du fait des triggers et autres intersections de la base collecteur. Soit automatiser le bloquage du trigger cor_area_synthese puis relancer la commande ensuite, soit au moins signaler ce point là dans la doc pour que l'utilisateur puisse anticiper. |
OK intéressant et merci pour ce gros récap ! Avant toute chose, je pense qu'il faut garder en tête qu'on peut aussi avoir des échanges de données entre instances GeoNature de manière plus simple, dans certains cas. Donc les 2 mécanismes doivent pouvoir cohabiter et on peut déjà réfléchir au cas simple où 1 API = Pour les sources, clairement c'est un référentiel local qui n'a pas vocation à être partagé. Je ne pense pas que le concept de "export standard pour instance GeoNature" soit vraiment pertinent. En effet dans mon GeoNature, je peux avoir différents exports (correspondant à différents exports) qui alimentent des GeoNature différents et de manière différent. Je pense aussi que si une valeur n'est pas reconnue dans la BDD du collecteur (taxon, cd_nomenclature...), alors elle est ignorée, idéalement loguée. Concernant la priorisation des données, dans un échange de données il doit y avoir une base maître et une base esclave. Y en a qu'une qui écrase l'autre en cas de différente. Je ne suis pas sur de voir pourquoi il faut faire 2 modes. L'import initial est le même que les suivants sauf qu'il est plus long et qu'il n'y a rien à mettre à jour, que des nouveautés. Mais c'est le même mécanique et le même processus. |
Travail initié dans https://github.com/lpoaura/gn2gn_client/tree/dev |
Je viens de publier une première pre-release avec la fonctionnalité de base permettant de rapatrier les données d'un export dans une base de données, stockées dans un champ JSON. Il s'agit d'une application Python exécutée depuis en ligne de commande (programmable avec un cron). Dépot: https://github.com/lpoaura/gn2gn_client Il reste principalement à développer :
|
Bonjour @lpofredc , Dans le cadre de la mission COBIODIV SI je vais essayer le développement effectué. Merci pour ce travail ! |
Bonjour @Adrien-Pajot, L'application a été renommée depuis en GN2PG (cf. lpoaura/GN2PG#5).
NB: La partie incrémentale n'est toujours pas finalisée. |
L'historisation des suppressions dans la Synthèse et l'API associée a été intégrée dans la version 2.12.0. |
Quel est votre position sur les réplications entre instances?
La région pays de Loire a une instance qu’elle veut faire communiquer avec une instance d’un Pnr local.
Nous pourrions utiliser un ETL, une réplication partielle de bases à bases, ou du code python dédié ?
Merci
The text was updated successfully, but these errors were encountered: