You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 ?
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?
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 :)
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)
The text was updated successfully, but these errors were encountered: