Skip to content
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

Questions sur l'historisation GeoNature du fournisseur de données #16

Open
lpofredc opened this issue Sep 13, 2021 · 2 comments
Open

Comments

@lpofredc
Copy link
Member

PR intégrant une historisation des données de la synthèse (insert, update, delete):

* Les `delete` sont loggés dans la table gn_synthese.t_log_synthese par triggers

* Les `update` & `insert` ne sont pas loggés par triggers car déjà présents dans gn_synthese.synthese par les champs `meta_{create,update}_date`.

* Le tout est regroupé dans une vue gn_synthese.v_log_synthese.

L'API, désactible par l'option ['SYNTHESE']['LOG_API'] = False, est basée sur la classe GenericQuery donc avec des possibilités de requêtage avancées (action supérieure à une date spécifique par exemple).

Cette API nécessaire pour la mise à jour incrémentale de Gn2Pg.

Lien avec #789

Bonjour, Une simple question sur ce point.

L'API va chercher l'historique des actions sur une donnée elle-même, pour aller la répliquer sur la base "cliente" via gn2pg. Du coup l'incrémental ne se fait pas en allant checker "les données reçues hier VS les données reçues aujourd"hui'.

Je comprends bien l'intérêt pratique, mais ça veut dire que si je mets à jour ma vue qui sert le client via GN2PG, il faut refaire une synchro complète ? Puisque j'aurai finalement dans cette nouvelle vue, retiré des données dont la dernière action n'est pas forcément "detele", j'aurai de nouvelles données dont la création n'est pas postéieure à la dernière synchro etc ?

Originally posted by @DonovanMaillard in PnX-SI/GeoNature#1456 (comment)

@lpofredc
Copy link
Member Author

En effet, si la vue d'export fait l'objet de modifications, il est préférable de procéder à un import complet des données.

Pour cette raison, l parait important de bien anticiper ce qui sera échangé dans le cadre d'un partage de données.

Le choix d'une mise à jour par comparaison de données entre fournisseur et destinataire peut en effet paraitre intéressant sur certains aspects mais me parait complexe à gérer pour de grosses quantité de données; l'objectif étant de lancer les mises à jojur incrémentales régulières(toutes les heures par exemple).

Ce fonctionnement n'est pas prévu à court terme. A discuter pour une v2?

@DonovanMaillard
Copy link

DonovanMaillard commented Sep 13, 2021

Oui, je comprends que sur les gros volumes, checker ce qu'on a reçu / ce qu'on a déjà peut compliquer les choses pour le client. Je voulais surtout m'assurer de bien cerner le fonctionnement, car la méthodo qu'on avait en tête ne fonctionnera pas du coup, on va réfléchir à une manière de s'adapter.

De notre coté, on prévoyait de passer les jeux de données à la fin des rendus de nos rapports par exemple. Donc on va périodiquement intégrer à la vue des données qu'on aura créées plusieurs semaines/mois plus tot (au délà de nos données hors études, qui elles passeront quotidiennement).
Mais ca ne me semble pas du tout être un soucis... tout ces exports sont basés sur des vues. On peut imaginer d'historiser ce qu'on passe ou non en diffusable, pour aller "surcoucher" la dernière action des données en question dans la vue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants