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

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

Open
lpofredc opened this issue Feb 6, 2020 · 12 comments
Labels
bug Something isn't working

Comments

@lpofredc
Copy link

lpofredc commented Feb 6, 2020

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
Capture d’écran - 2020-02-06 à 11 48 59

Après plusieurs rafraichissements, on obtient une bonne représentation.
Capture d’écran - 2020-02-06 à 11 51 17

@camillemonchicourt
Copy link
Member

camillemonchicourt commented Feb 6, 2020

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

@camillemonchicourt camillemonchicourt added the bug Something isn't working label Apr 8, 2020
@lpofredc
Copy link
Author

lpofredc commented Apr 9, 2020

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
Copy link

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 ?

@TheoLechemia TheoLechemia changed the title Rendu aléatoire de la vue matérialisée de synthèse par cadre d'acquisition Rendu aléatoire de la vue matérialisée de synthèse par cadre d'acquisition - CA dédoublés Mar 17, 2021
@gildeluermoz
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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

@TheoLechemia
Copy link
Member

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 :

dashboard

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
Copy link

@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
Copy link
Member

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
Copy link
Member

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 :

dashboard_pr_bug2
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 :
dashboad_pr_good
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
Copy link

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
Copy link
Member

OK pour moi. Merci.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants