Rendu aléatoire de la vue matérialisée de synthèse par cadre d'acquisition - CA dédoublés

[lpofredc]

Le rafraichissement de la synthèse par cadres d'acquisition montre des comportements hasardeux qui éclatent les cadres d'acquisition en plusieurs datasets comme l'illustre la capture suivante

Après plusieurs rafraichissements, on obtient une bonne représentation.

[camillemonchicourt]

Oui j'ai constaté ça aussi parfois. J'ai pensé à un problème de jointure mais si ça ne le fait pas à chaque fois...
Il faudrait voir avec @ElsaGuilley AKA @eguilley

[lpofredc]

Pour faire suite au ticket #18. Ce que j'ai constaté, c'est que la génération de la vue matérialisée du nombre de données par CA et par années éclate les cadres d'acquisition sans raison apparente. Ainsi la table organisée comme suit éclate la donnée lors de la sérialisation et génère 3 CA (CA1 doublé et CA2). Ce qui me surprend vu la requête de cette VM.

CA	annee	nbobs
CA1	2003	20
CA1	2004	25
CA2	2000	10
CA2	2001	7
CA1	2005	40

SELECT DISTINCT af.acquisition_framework_name,
    date_part('year'::text, s.date_min) AS year,
    count(*) AS nb_obs
   FROM gn_synthese.synthese s
     JOIN gn_meta.t_datasets d ON d.id_dataset = s.id_dataset
     JOIN gn_meta.t_acquisition_frameworks af ON af.id_acquisition_framework = d.id_acquisition_framework
  GROUP BY af.acquisition_framework_name, (date_part('year'::text, s.date_min))
  ORDER BY af.acquisition_framework_name, (date_part('year'::text, s.date_min))

Il me semble que l'éxécution du refresh hors de la fonction fonctionne mieux. Peut-être (mais je ne vois pas vraiment pourquoi) une interaction entre rafraichissements liés au paramètre "concurrently" ?

[xavyeah39]

Mystérieux cette affaire...
En regardant à nouveau la définition de la vue, je l'ai modifiée juste en changeant le type de jointure sur les CA en la passant en LEFT (ce qui ici ne change en rien la table résultante).
Je rafraîchi le dashboard et pouf : ma doublette a disparue...!
Je refais la manip en sens inverse pour revenir à un simple JOIN, je rafraîchi le dashboard à nouveau.... mince pas de retour de doublette pour confirmer...

Etrange... en tout cas côté bdd, je ne vois pas le soucis ni en quoi ce changement de join, le paramètre concurrently ou les refresh dans la fonction pourraient être en cause.
Peut-être plutôt côté front dans la génération des classes des graphiques ?

[gildeluermoz]

Merci pour vos échanges sur le sujet. De mon coté, même constat mais les rafraichissements de l'interface web ne changent rien. Dans ton cas @xavyeah39 le rafraissement s'est peut-être fait entre 2 refresh du crontab.
De mon coté, j'ai pu constater que le soucis venait probablement du ORDER BY qui se fait mal. Le contenu de la matérialzed view s'affichait avec des items d'un même CA au début et d'autres à la fin. L'affichage sur le graphique se faisait selon l'ordre d'affichage dans la vm. Après suppression et recréation de la VM, tout est bon. mais que va t-il se passer après le refresh dans le cron.
Il est donc probable que le code itère sur la table de la vm ligne par ligne et crée un élement dans la légende et sur le graphique chaque fois que le CA change de nom. Je ne maitrise pas le code du dashbord mais il faudrait peut-être le reprendre pour éviter ces aléas.
Maintenant, comme le dit @lpofredc, pourquoi la vm ne respecte pas le order by. C'est une autre histoire.

[gildeluermoz]

en lisant le code, je comprends que ça se passe autour de ceci : https://github.com/PnX-SI/gn_module_dashboard/blob/master/frontend/app/dashboard/dashboard-frameworks/dashboard-frameworks.component.ts#L202

Je ne maitrise pas typescript mais @bouttier ou @TheoLechemia devrait savoir nous dire si on peut faire un .sort sur le array this.adjustedData coté front.

J'ai trouvé des trucs du genre pour faire un sort avec une fonction selon une clé du array :

let arr:{key:number}[] = [{key : 2}, {key : 3}, {key : 4}, {key : 1}, {key : 5}, {key : 8}, {key : 11}];
let sortFn2 = (obj1 , obj2) => {key:number} { return obj1.key - obj2.key; }
const sortedArray2:{key:number}[] = arr.sort(sortFn2);

Je n'ai pas regardé comment sont préparées les données coté backend. C'est peut-être plus facile avec python.

[camillemonchicourt]

Oui l'idéal serait plutôt que le backend renvoie les données correctement et dans l'ordre souhaité.

[TheoLechemia]

Le problème a bien l'air d'être côté frontend.
En fait la structure de ce que renvoie le backend est un peu particulière :
[ [ "ABC du PNE", 2018.0, 1657 ], [ "ABC du PNE", 2019.0, 593 ], [ "ATBI Lauvitel", 1992.0, 16 ], [ "ATBI Lauvitel", 1993.0, 184 ], [ "ATBI Lauvitel", 1994.0, 263 ], [ "ATBI Lauvitel", 2008.0, 4 ] ] ...
je verais bien un truc comme ça :
[{"acquisition_framework": "ATBI du Lauvitel", "data" : [{"year": 1900, "nb_data" : 150}, {"year": 1901, "nb_data" : 155}] ... ça évite à devoir faire un filtre côté frontend.
De plus, quand on a beaucoup de CA ça devient franchement illisible :

je vous propose de faire évoluer un peu l'interface, pour ajouter un "input" permettant de sélectionner un ou plusieurs cadre d'acquisition. L'api, elle renverrais la structure de données décrite plus haut.
Dites moi ce que vous en pensez ?

[jpm-cbna]

@TheoLechemia Oui, l'ajout d'un champ permettant de sélectionner un ou plusieurs CA me semble être une bonne idée pour gérer les installations de GN possédant beaucoup de CA.
Par contre, par défaut, il serait bien que le graph affiche quand même quelque chose. En sélectionnant les 5 premiers par exemple ?

[TheoLechemia]

Oui je me demandais aussi quoi mettre par défaut ? Mais du coup, 5 au hasard ? Les 5 qui on le plus de données ?

[TheoLechemia]

J'ai un peu avancé sur le sujet.
Premier point : je pense qu'il faut passer le graphique en histogramme : actuellement le graphique en ligne entraine des problème de représentation :

Ex : le CA "litière forestière" n'a aucune données entre 2001 et 2020 et le graphique affiche une ligne continue laissant pensé qu'il y a des données entre ces deux années.
En mode histogramme, on a plus ce problème :

Le graphique en histogramme se prête moins à afficher "beaucoup" de CA, du coup je propose de la laisser vide par défaut plutôt que d'en mettre au hasard

[jpm-cbna]

Le graphique en histogramme se prête moins à afficher "beaucoup" de CA, du coup je propose de la laisser vide par défaut plutôt que d'en mettre au hasard

Oui, ou alors afficher par défaut celui qui possède le plus de données...

[camillemonchicourt]

OK pour moi. Merci.