search

PnX-SI / gn_mobile_occtax

Application mobile pour la saisie dans le module Occtax de GeoNature
GNU General Public License v3.0
13 stars 5 forks source link

Récupération partielle des taxons #52

Closed DonovanMaillard closed 3 years ago

DonovanMaillard commented 4 years ago

Bonjour,

Je viens de tenter une install de geonature mobile. TaxHub (1.7) et Usershub (2.1.2) sont à jour, GeoNature est dans sa version master actuelle 2.3.2.

Pour info et question : L'application mobile me remonte bien les JDD, les observateurs, en revanche elle ne récupère que 27 taxons sur 6105 présentes dans ma liste saisie occtax (dont l'identifiant est bien renseigné dans settings_occtax). Est-ce un bug à rechercher sur l'appli mobile, sur la synchronisation, ou simplement des routes mises à jour dans la prochaine version GeoNature puisque j'ai vu qu'un travail avait été fait là dessus?

Merci !

camillemonchicourt commented 4 years ago

Attention l'application Occtax-mobile nécessite à minima TaxHub 1.7.0 ainsi que GeoNature 2.4.0.

Mais là ton soucis semble bien du côté de TaxHub. La route récupère les taxons par lot, en utilisant les paramètres page_size et page_max_retry (https://github.com/PnX-SI/gn_mobile_core/tree/master/sync#parameters-description) pour savoir combien d'objets remonter à chaque fois et combien de fois boucler. Mais avec les paramètres par défaut, elle peut remonter jusqu'à 20000 objets (20*1000). Donc cela ne semble pas un soucis au niveau de ces paramètres.

Quand tu es passé à TaxHub 1.7.0, as-tu bien appliqué les mises à jour de la BDD et notamment le rafraîchissement de la vue matérialisée taxonomie.vm_taxref_list_forautocomplete qui reprend le contenu de tout Taxref ?

Tu peux tester ta route en web aussi pour voir ce qu'elle remonte. Voir https://github.com/PnX-SI/gn_mobile_core/issues/13

DonovanMaillard commented 4 years ago

Ok merci pour ta réponse,

En effet j'ai bien lancé le script de mise à jour 1.6.5to1.7.0, et je n'ai pas eu d'erreurs particulières. J'ai quand même vérifié pour être sur et ma vue est bien conforme à ce que crée le script d'update vers 1.7.0.

La route testée coté web remonte bien mes 6105 noms https://taxons.flavia-ape.fr/#!/listes/100

En revanche sur ces paramètres par défaut, j'ai 

"page_size": 100,
 "page_max_retry": 5

dans le code partagé ici. Je vais peut être déjà commencé par remonter ces variables pour nous donner du mou.

(ha, et j'ai vérifié aussi, je n'ai pas de filtre activé)

camillemonchicourt commented 4 years ago

Ton URL là est la page web de l'application, pas la route. La route est : https://taxons.flavia-ape.fr/api/taxref/allnamebylist/100?limit=10000

DonovanMaillard commented 4 years ago

Oups mauvais lien, ok merci. La route renvoie donc 5009 lignes, pour 6105 noms dans ma liste.

Ca laisse quand même penser à un soucis coté mobile à priori, qui ne remonte que 27 noms, ou à un soucis lors de la synchronisation ? Screenshot_20200622-130558_Occtax

DonovanMaillard commented 4 years ago

J'ai coupé et relancé l'appli de synchronisation (qui avait bien sa pastille verte tout à l'heure) et elle est en train de récupérer. A priori c'est donc simplement un soucis de synchronisation, connexion perdue, transaction stopée ou autre qui serait à l'origine du soucis... je vous dirai si j'arrive à avoir mes 6105 noms à l'issue de cette synchro, qui effectivement dure plus longtemps

Complément : après cette nouvelle synchronisation j'ai 1364 taxons. De nouveau pastille verte, pas possible de relancer une synchro manuellement. Des transactions qui ne se terminent pas quelque part à priori?

camillemonchicourt commented 4 years ago

La synchronisation des taxons paginée a été réglée au niveau de TaxHub 1.7.2 ainsi que Sync-mobile 0.3.

samuelpriou commented 3 years ago

Bonjour à tous,

Nous rencontrons un souci lors de la synchronisation. Nous utilisons la version 1.1.4 de Occtax mobile et la version 1.1.2 pour la synchro. GeoNature est en version 2.5.5 et Taxhub 1.7.3

Des taxons qui étaient auparavant disponible à la saisie mobile (ex : Bouquetin des Alpes, Chamois, Roitelet à triple bandeau, etc) ne sont plus disponible dans Occtax mobile. Or la data synchronisation aboutit (pastille verte).

Screenshot1

Dans taxhub, la liste (id=500) contient 11974 noms : https://geonature.mercantour-parcnational.fr/taxhub/#!/listes/500.

En BDD, dans la vue v_taxef_all_listes, nous avons également 11974 noms pour la liste 500. Or après avoir lancé une synchronisation, Occtax mobile annonce seulement 8890 taxons trouvés.

Screenshot2

La route : https://geonature.mercantour-parcnational.fr/taxhub/api/taxref/allnamebylist/500?limit=20000 remonte 17180 taxons dont les taxons Bouquetin des Alpes, Chamois, Roitelet à triple bandeau qui sont présent.

Que conviendrait il de faire pour que nous récupérions l'intégralité des taxons dans Occtax mobile ?

PS : j'ai déjà lancé un refresh materialized view sur vm_taxref_list_forautocomplete

Merci pour votre aide.

TheoLechemia commented 3 years ago

Bonjour, désolé Samuel, je ne réponds pas directement à ta question, mais j'en pose une autre. Au vu des nombreux retours de problème de synchronisation (perfs et incohérence des données), je me pose la question de la pertinence d'utiliser les API existantes pour récupérer les référentiels. Ces routes n'ont pas vraiment été taillés pour ça et on voit que l'ancienne solution, c'est à dire ajouter un endpoint qui se charge de construire une base Sqlite, marchait mieux. Est-ce qu'on ne pourrait pas avoir un fonctionnement hybride:

camillemonchicourt commented 3 years ago

Oui c'est surtout la synchronisation des unités géographiques qui est lourde et parfois n'aboutit pas. Des solutions d'amélioration de la synchronisation sont en cours par ailleurs. Revoir la logique de synchronisation en générant le SQLite côté serveur sont une piste mais nécessiterait une importante refonte en effet.

Pour le problème de Samuel, il y a eu plusieurs échanges sur le sujet. C'est normal que le nombre de taxons soient différents car l'application mobile de charge de regrouper les lignes correspondant aux noms latins et aux noms français. Il y a peut-être un soucis à ce niveau pour les taxons que tu ne retrouves pas dans l'application mobile. Tu peux analyser ça en analysant les différents logs, mais aussi en ouvrant la BDD SQLite présente sur l'appareil mobile.

samuelpriou commented 3 years ago

Bonjour, désolé Samuel, je ne réponds pas directement à ta question, mais j'en pose une autre. Au vu des nombreux retours de problème de synchronisation (perfs et incohérence des données), je me pose la question de la pertinence d'utiliser les API existantes pour récupérer les référentiels. Ces routes n'ont pas vraiment été taillés pour ça et on voit que l'ancienne solution, c'est à dire ajouter un endpoint qui se charge de construire une base Sqlite, marchait mieux. Est-ce qu'on ne pourrait pas avoir un fonctionnement hybride:

* utiliser les API existantes pour les POST

* construire une API séparée pour les besoins de synchronisation
  J'ai conscience que ça necessite une refonte assez importante de l'existant.. (surement à discuter dans un ticket séparé)

Les retours que nous avons des agents sur le processus de synchronisation sont de manière générale négatifs à cause des performances très limitées (durée de la synchro, échec de la synchro et parfois incohérence des données). A titre de comparaison nous avions moins d'échecs de synchronisation avec la version V1 de Geonature mobile.

camillemonchicourt commented 3 years ago

Il y a 3 pre-release en cours de l'outil Sync-mobile, notamment en lien avec le sujet https://github.com/PnX-SI/gn_mobile_core/issues/34

Un élément identifié est qu'il y a beaucoup d'appels des routes de GeoNature qui sont longs et parfois trop lourds. Un moyen d'améliorer le temps et la réussite des synchronisations est d'augmenter le paramètre page_size. En le passant de 1000 à 10000, c'est plus rapide et ça aboutit plus facilement.

samuelpriou commented 3 years ago

Je suis allé regarder de plus près le fichier de log généré sur le smartphone. La synchro aboutit

_04-07 14:56:03.692 10209 10291 I fr.geonature.sync.sync.worker.DataSyncWorker: l ocal data synchronization successfully finished in 227783ms 04-07 14:56:03.699 10209 10255 I WM-WorkerWrapper: Worker result SUCCESS for Wor k [ id=7c7d5e9e-91b8-4a7f-bcda-8a211de24fb6, tags={ fr.geonature.sync.sync.worke r.DataSyncWorker, data_sync_workertag } ]

Cependant la table data de la BDD SQLite indique l'absence des taxons chamois, bouquetins etc. data

samuelpriou commented 3 years ago

En passant le paramètre page_size de 1000 à 10000, j'ai pu récupérer tous les taxons manquants. Occtax mobile annonce 11974 taxons trouvés, identiques à ceux de la liste (id=500) qui contient elle aussi 11974 taxons.

C'est bizarre que la synchro passait encore il y a peu avec le paramètre page_size à 1000.

Merci !

camillemonchicourt commented 3 years ago

Ah OK donc la synchro semblait passer, mais en fait elle ne devait pas aboutir et cela expliquait ton soucis de noms manquants dans la liste ! OK à noter pour alimenter les discussions actuelles avec @sgrimault sur la synchronisation.

samuelpriou commented 3 years ago

Bonjour,

Je reviens sur ce ticket car nous rencontrons à nouveau un souci pour des taxons manquants dans Occtax mobile. Nous utilisons toujours la version 1.1.4 de Occtax mobile et la version 1.1.2 pour la synchro. GeoNature est en version 2.5.5 et Taxhub 1.7.3

La synchro passe sans problème semble t'il :

_05-25 11:57:03.084 26717 26749 I fr.geonature.sync.sync.worker.DataSyncWorker: l ocal data synchronization successfully finished in 102989ms 05-25 11:57:03.088 26717 26739 I WM-WorkerWrapper: Worker result SUCCESS for Wor k [ id=11450b90-042f-40a5-8f3a-704179ed6ca8, tags={ fr.geonature.sync.sync.worke r.DataSyncWorker, data_sync_workertag } ].

Dans taxhub, la liste (id=500) contient 11974 noms : https://geonature.mercantour-parcnational.fr/taxhub/#!/listes/500.

En BDD, dans la vue v_taxef_all_listes, nous avons également 11974 noms pour la liste 500. Or après avoir lancé une synchronisation, Occtax mobile annonce seulement 6688 taxons trouvés et cela se confirme lorsque j'ouvre le fichier data.db stocké sur le téléphone.

data

amandine-sahl commented 3 years ago

Est-ce que ce n'est pas lié à la différence entre taxon et nom ? Ici seul les taxons sont considérés.

samuelpriou commented 3 years ago

A priori non car habituellement j'ai approximativement 11974 taxons annoncés pour Occtax mobile. Et là après la synchro il manque bien de nombreux taxons. Il manque notamment des papillons (Colias alfacariensis - le fluoré). Lui est notamment présent à la saisie dans Occtax. data_1

amandine-sahl commented 3 years ago

Je n'avais pas fait attention à la version d'occtax mobile que tu utilises.
Je pense que c'est en partie lié à l'issue https://github.com/PnX-SI/gn_mobile_core/issues/34 de l'application sync. C'est normalement corrigé. Essaye avec les nouvelles version de l'application de synchronisation

samuelpriou commented 3 years ago

@amandine-sahl tu me conseilles d'installer uniquement la dernière version de sync 1.1.7 ? Faudrait il que j'installe également la dernière version de Occtax_mobile ou est ce que cette version 1.1.7 est compatible avec un occtax-mobile 1.1.4 ? Merci

samuelpriou commented 3 years ago

Bonjour, J'ai installé la dernière version de sync sur mon téléphone. J'ai lancé la synchro qui passe sans problème mais je me retrouve toujours avec des taxons manquants. Occtax mobile propose seulement 6688 taxons alors que nous devrions en avoir 11974.

camillemonchicourt commented 3 years ago

Je crois qu'on en a discuté ailleurs, mais Occtax-mobile regroupe les noms scientifiques et les noms français en une seule ligne, donc il y a toujours une différence entre le nombre de lignes dans la table et dans la route et dans ce qu'affiche Occtax-mobile. Cela explique peut-être la différence ?

samuelpriou commented 3 years ago

Non mon problème ne vient pas de là. Il manque des taxons dans la bdd sqlite qui est déposée sur Phone\Android\data\fr.geonature.sync\databases. Pourtant la synchro aboutit.

samuelpriou commented 3 years ago

Les taxons manquants sont présent à la saisie dans Occtax-web

DonovanMaillard commented 3 years ago

Sans doute à discuter plutôt sur le dépôt de sync ;)

Tu es su quelle version de sync?

samuelpriou commented 3 years ago

@DonovanMaillard. Nous sommes sur une version 1.1.2 de sync. J'ai également testé la dernière version 1.1.9 mais j'obtiens le même comportement. Seulement 6688 taxons sur Occtax mobile quand j'ai ai 11975 sur https://geonature.mercantour-parcnational.fr/taxhub/#!/listes/500

camillemonchicourt commented 3 years ago

Et tu as quoi comme paramètres pour :

?

DonovanMaillard commented 3 years ago

Pas très recommandé à priori, mais j'ai "réglé" ou en tous cas contourné, le soucis chez Flavia en mettant un page_size très élevé. Un seul appel suffit par conséquent, et ça fonctionne comme ça.

amandine-sahl commented 3 years ago

Ce n'est pas exactement le même soucis mais dans notre cas :

Liste avec :

et la table data_taxon contient 8583 données dans la table taxons

Exemple avec Rhagadiolus edulis Requete tous les taxons ayant la description Rhagadiolus edulis dans data_taxon : image

Requête de taxref: image

Bref je ne comprend pas tout à l'algorithme de récupération des taxons

DonovanMaillard commented 3 years ago

Pour quelle raison le choix a été fait à l'origine d'un tel traitement des noms ?

Le soucis se pose pour beaucoup, le traitement est assez opaque. En théorie, on devrait avoir autant de ligne que de cd_nom saisissables, avec leurs noms latin + nom francais concaténés? Le traitement est plus compliqué que ça aujoud'hui?

samuelpriou commented 3 years ago

Et tu as quoi comme paramètres pour :

* page_size

* page_max_retry

?

Voici nos paramètres dans le fichier settings_sync.json { "geonature_url": "https://geonature.mercantour-parcnational.fr", "taxhub_url": "https://geonature.mercantour-parcnational.fr/taxhub/", "uh_application_id": 14.0, "observers_list_id": 1.0, "taxa_list_id": 500.0, "code_area_type": "UG", "page_size": 10000.0, "page_max_retry": 5000.0 }

DonovanMaillard commented 3 years ago

quand j'ai ai 11975

avant d'avoir une solution plus "propre", tu peux essayer page_size: 20000 et page_max_retry: 10 ou 20 peu importe. Ca a marché pour nous.

samuelpriou commented 3 years ago

quand j'ai ai 11975

avant d'avoir une solution plus "propre", tu peux essayer page_size: 20000 et page_max_retry: 10 ou 20 peu importe. Ca a marché pour nous.

@DonovanMaillard. Ok je teste

samuelpriou commented 3 years ago

La synchro passe mais j'ai toujours que 6688 taxons 😭

sgrimault commented 3 years ago

Bonjour @samuelpriou Pourriez vous me communiquer les traces logcat de l'application de synchronisation ?

Pour information et suite à différents échanges précédents sur la partie synchronisation des données, il n'y a plus de conditions lors de l'insertion des taxons, mais uniquement sur la partie des données relatives aux zones géographiques pour les taxons (le taxon doit au préalable exister). Comme la base des taxons peut être assez volumineuse, le traitement se fait de manière séquentiel par "page" (via les paramètres page_size et page_max_retry) pour enchaîner les appels à la route paginée /api/taxref/allnamebylist. Si un des appels échoue, le traitement continue jusqu'à ce que le route /api/taxref/allnamebylist réponde par un 404 (non trouvé) ou que le paramètre page_max_retry est atteint. Il est possible que sur l'ensemble du traitement certains appels tombent en échec (d'où le delta constaté). Pour réduire le nombre d'appels à faire (et donc le risque d'erreurs), on peut aussi augmenter la valeur du paramètre page_size (par défaut il est fixé à 1000 taxons). Voici un rappel des règles pour faciliter ce paramétrage :

samuelpriou commented 3 years ago

@sgrimault. Voici les logs de l'application sync. A priori la synchro passe correctement mais il manque des taxons à la saisie mobile alors que les taxons sont bien ouverts à la saisie et présents en saisie web. Merci logcat

samuelpriou commented 3 years ago

@sgrimault En passant les paramètres suivant : "page_size": 20000.0, "page_max_retry": 70.0

Cela résout mon problème. J'ai bien 11975 taxons ouvert à la saisie. La liste est complète.

sgrimault commented 3 years ago

@samuelpriou, je te laisse clore le ticket :)

camillemonchicourt commented 3 years ago

@sgrimault il n'y a rien à faire du fait que cela ne fonctionnait pas en aillant des paramètres plus bas qui faisaient alors 2 appels à la route des taxons et ont entraîné une récupération partielle de la liste ?

DonovanMaillard commented 3 years ago

Oui, le fonctionnement reste très capricieux sur ce point et le nombre d'appels défini ne semble pas avoir le comportement espéré. Il faut y aller à tâton pour trouver les variables qui fonctionnent pour l'instant

sgrimault commented 3 years ago

Vu avec @samuelpriou, les taxons étaient incomplets car le paramètre page_max_retry était trop petit. Pour être sur de pouvoir récupérer tous les taxons (et leurs données relatives), il faut s'assurer que page_size * page_max_retry couvre bien la base des taxons à synchroniser. Pour le cas de Samuel, il y a environ près de 12k taxons à synchroniser mais aussi près de 1.3M d'entrées liées aux données relatives des taxons. Donc avec un page_size fixé à 20k et page_max_retry à 70 on arrive donc 1.4M d'entrées.

DonovanMaillard commented 3 years ago

d'une manière générale, est-il pertinent de laisser à l'utilisateur la définition d'un max_retry? Dans la mesure où l'appli gère déjà les choses assez intelligemment en testant les pages completes/incomplètes, les echecs d'appels etc ? Est-ce qu'on pourrait pas avoir simplement le page_size à définir, et que l'appli aille elle-même fixer son max_retry en fonction du nombre de taxons retourné par la route pour éviter ce type de soucis?

Pour ma part, la notion d'entrées relatives aux taxons, en dehors des noms eux-mêmes m'échappait totalement. J'arrêtais mon calcul au nombre de taxons renvoyés par l'api.

sgrimault commented 3 years ago

C'est plus un garde fou pour garantir que la synchronisation s'arrêtera bien. Actuellement le module de synchronisation "navigue" dans la route paginée /api/taxref/allnamebylist tant que cette dernière répond toujours 200. Le cas d'arrêt est d'avoir en retour une erreur 404 (ressource non trouvée) ou que la valeur du paramètre page_max_retry a été atteinte.

DonovanMaillard commented 3 years ago

D'accord merci. Peux-tu me préciser quelles sont les ressources relatives dont il faut tenir compte dans le calcul en plus du nombre de taxons et où elles se trouvent, pour qu'on puisse le préciser dans la doc?

camillemonchicourt commented 3 years ago

Les données relatives aux taxons sont les couleurs des taxons pour toutes les unités géographiques.

DonovanMaillard commented 3 years ago

Ok merci, donc impossible de prévoir facilement le volume que ça représente sur une instance moyenne pour proposer des paramètres par défaut. Dommage !

sgrimault commented 3 years ago

Pour simplifier, on pourrait rendre le paramètre page_max_retry facultatif et la synchronisation ne s’appuiera alors que sur la valeur de retour de l'API (404 on s'arrête là) ou sur le nombre d'entrées récupérées par rapport à la valeur fixée de page_size (si le nombre d'entrées récupérées est inférieur à page_size alors on s’arrête là).

Et on part du principe que le comportement coté API restera inchangé :

DonovanMaillard commented 3 years ago

Disons qu'il faut à minima le décrire précisément dans la doc et préciser où trouver le nombre de lignes que l'appli mobile a besoin de récupérer pour calculer correctement ces variables, à moins de pouvoir le simplifier effectivement. Mais en effet, faire evoluer ses unités géographiques, ses taxons ou autre, peut engendrer ce type de soucis par conséquence. Ca oblige à surveiller ces paramètres là... c'est peut-être pas la principale priorité dans un premier temps mais ça mérite d'être réfléchi et simplifié je pense

camillemonchicourt commented 3 years ago

OK, pour conclure ce sujet et bien comprendre. Cela signifie que si le récupération des couleurs des taxons par unités géographiques se fait partiellement (car le page_max_retry est atteint ou autre), alors la liste des taxons sera aussi récupérée partiellement, ou seulement affichée partiellement ? Ça je ne comprends pas pourquoi.

lepontois commented 3 years ago

Avant de conclure, j'aimerais ajouter mon grain de sel...

J'ai 137 549 lignes dans gn_synthese.v_color_taxon_area (contenant 13517 cd_ref différent) et une liste de 9715 taxons que je souhaite autoriser à la saisie mobile. J'ai paramétré de façon très large page_size=10000 et page_max_retry=20000 pour être sûr de tout couvrir.

Bilan :

edit : j'ai pas précisé, je suis en GN 2.6.2 et en sync 1.1.9 et occtax-mobile 1.2.4

sgrimault commented 3 years ago

@lepontois J'aurais besoin des traces logcat de l'application de synchronisation voir si il n'y aurait pas des appels qui tombent en échec. Comme expliqué ci-dessus, le paramètre page_max_retry est en fait le nombre d'appels maximal que pourra faire l'application de synchronisation. Il n'est pas nécessaire de mettre une valeur si grande (20000, ça veut donc dire qu'on est prêt à lancer près de 20000 requêtes ! Ce qui est beaucoup trop).

Dans votre cas, je testerais avec les paramètres suivants :