Table de liaisons non historisées
Closed this issue · 1 comments
Les informations des tables de liaisons cor_zp_obs et cor_ap_perturb mériterait d'être historisé d'une manière ou d'une autre. En effet, les tables t_zprospect et t_apresence sont historisés mais sans leurs tables de liaison. Une partie de l'information est donc perdue.
Une solution serait de stocker dans des colonnes des tables t_zprospect et t_apresence les informations des tables de liaison sous forme de chaines concaténées.
Pour t_zprospect une chaîne concaténée correspondant aux observateurs (cor_zp_obs).
Pour t_apresence une chaîne concaténée correspondant aux perturbations (cor_ap_perturb).
Pour ce faire nous pourrions encapsuler l'appel de la fonction gn_commons.fct_trg_log_changes() dans notre propre fonction qui se chargerai de mettre à jour les tables t_zprospect et t_apresence avant de faire appel à gn_commons.fct_trg_log_changes().
Fait dans le commit 38fa643.
Finalement, ce sont des triggers (INSERT, DELETE) sur les tables de liaison (cor_zp_obs, cor_ap_perturb) qui mettent à jour le champ additional_data de leur table principale (t_zprospect, t_apresence).
Cela provoque autant d'ajout dans la table d'historisation que de suppressions/ajouts dans les tables de liaisons... Je n'ai pas trouvé de solution pour déclencher l'appel de la création de l'info dans additionnal_data, une fois tous les changements faits.