liste tronquée saisie observation #323
Comments
|
Bien vu, Ça semble dû a la pagination de la route de TaxHub. |
|
Je sais pas quelle route de TaxHub est utilisée mais ça vaut peut-être le coup d'utiliser la même qu'Occtax optimisée pour l'autocompletion avec optimisation des résultats, recherche en français ou nom scientifique etc... ? |
|
Merci pour vos retours, Je me réjouis de voir des réponses mais je suis tout de même inquiet. Je suis surpris que malgré la multiplication des atlas de la biodiversité ce problème n'ait pas été signalé. Je risque d'avoir un problème dans la mesure où notre atlas doit être opérationnel mi-décembre et que ce comportement était totalement inattendu. Je suis preneur de pistes de travail. J'avoue que les "routes" ne m'évoquent pas grand chose pour l'instant (api ??) Merci encore pour votre aide. |
|
A ma connaissance, GeoNature-citizen n'a pour le moment été utilisé que pour des programmes avec des listes de taxons très limitées, ce qui fait que le soucis n'a peut-être pas été identifié. Je ne sais pas exactement où on en est de ces sujets. A voir quelle route de l'API TaxHub est utilisé, si elle peut être utilisée différemment pour ne pas avoir de limite de nombre de taxons, si il faut faire évoluer la route au niveau de TaxHub, ou si il faut mieux basculer sur une autre route de TaxHub... |
|
Bonjour, Effectivement si je ne dis pas de bêtises voici les étapes :
Éventuelle solutionJe n'ai pas testé mais je pense qu'il faudrait remplacer le dictionnaire payload : GeoNature-citizen/backend/gncitizen/utils/taxonomy.py Lines 28 to 33 in 2f937ff Par le code suivant : payload = {
"existing": "true",
"order": "asc",
"orderby": "taxref.nom_complet",
"limit": 5000
}C'est un fix rapide pour toi mais à terme il faudrait peut-être le rendre paramétrable. Je teste ça maintenant En espérant avoir été clair. |
|
J'ai pas trop le temps de tester sur citizen mais en exécutant ce code Python : import requests
>>> payload = {
"existing": "true",
"order": "asc",
"orderby": "taxref.nom_complet",
"limit": 5000
}
# 100 : id de ma liste taxhub
res = requests.get('http://localhost/taxhub/api/biblistes/taxons/100', params=payload)J'ai cette requête qui apparaît : Et j'ai @jonath35, peux-tu me tenir au courant si ça fonctionne chez toi ? |
|
Bonjour, Je test ça dès demain matin et vous tiens au courant. |
|
Bonjour, J'ai testé rapidement, mais cela ne semble pas fonctionner. à voir si je m'y prends correctement.
|
|
C'est étrange, cela fonctionnait bien avant cette modification ? Car normalement, elle ajoute uniquement un paramètre à la requête taxhub et ne devrait pas faire planter cet appel à l'API citizen. |
|
Oui c'est bien une liste particulière qui fonctionne bien (dans la limite des 100 premières lignes). Ce qui me questionne le plus, c'est qu'après avoir constaté cela, j'ai tenté de modifier la limite "en dur" dans le fichier :
avec pour résultat un comportement similaire (erreur). |
|
Effectivement, c'est étrange. |
|
avec l'url : http://xyza/taxhub/api/biblistes/taxons/10000?existing=true&order=asc&orderby=taxref.nom_complet&limit=5000 J'obtiens bien un résultat json avec les 3102 objets
|
|
l'adresse : http://xyza/api/taxonomy/lists/10000/species
|
|
Cela vient donc de Citizen, tu as pu regarder les logs ? |
|
Bonjour, Je trouve l'erreur suivante dans /var/log/supervisor/frontend_citizen.log :
Elle est présente dans le panneau de debugage du navigateur. Merci |
|
Super merci, et as-tu regardé le var/log/gunicorn_gncitizen_errors.log pour voir les erreurs du backend ? Car j'ai l'impression que ça vient de là (car c'est uniquement là que tu as fait la modification normalement ?) |
|
Merci pour le retour. Pour le test et l'erreur actuelle, la modification est celle proposée avec le dictionnaire payload (/backend/gncitizen/utils/taxonomy.py) Par contre je n'ai pas d'erreur backend il me semble. à part un retour"timeout" :
|
|
Non c'est juste un moyen d'indiquer le type d'une variable en Python. Mais comme il n'y a pas de vérification de type ici, cela ne pose pas de problème. |
|
C'est dingue de ne même pas pouvoir modifier la valeur 100 dans routesbiblistes.py .. Merci ! |
|
Merci pour les fichiers. Ils ont l'air bons. Peut-être, essaie de te mettre en mode dev sur le backend de citizen :
Ensuite entre cet URL dans ton navigateur : Désolé de ne pas pouvoir t'aider plus... |
|
Merci pour votre aide, J'ai stoppé toutes les appli supervisorctl stop all sur l'url xyza/api/taxonomy/lists/10000/species j'obtiens (dans le navigateur) :
En navigant sur la page programme :
|
|
J'ai obtenu un peu plus de résultat. il y avait des valeurs nulles dans le champs nom_francais de bib_noms. En effet, j'ai du reprendre une liste basée sur taxref 12 dans une base taxref 14. Cela a visiblement conduit à des valeurs null dans le champs en question et fait planté l'outil. J'ai pu obtenir un chargement normal avec dans le dictionnaire payload la clé,valeur "limit": 1000 Je vous remercie d'avoir consacré du temps à m'aider. |
|
Super bien joué ! Effectivement peut-être cela vient du timeout ici : Essaie de le mettre à 10 par exemple. |
|
Le chargement est vraiment très long / trop long je pense pour un usage normal. |
|
Ah oui effectivement, très bizarre... |
|
Comme évoqué, l'idéal serait certainement d'utiliser la route de TaxHub dédiée à la recherche de taxon avec auto-complétion, optimisée en terme de résultat et de pertinence et utilisée dans Occtax. |
|
OK je fais une PR dans ce sens |
|
En effet, il faut limiter au max les surcouches et redondances inutiles. |
|
Pensez-vous que le travail nécessaire est long ? Merci ! |
|
J'ai un peu commencé, je vais essayer de continuer cette semaine mais je ne peux rien te garantir... |
|
Super ! |
|
Après de nouveaux tests, j'ai des résultats différents. L'appel api http://xyza/api/taxonomy/lists/10000/species retourne bien les près de 3000lignes demandées (+/-40sec). Aucune erreur n'apparait. Une fois les résultats obtenus, le front, même dans une fenêtre privée ou autre navigateur, se charge sans délais (cache du serveur ?) Par contre, en redémarrant le fonctionnement normal, le problème réapparait ?? |
|
Oui, il ne faut vraiment pas un fonctionnement où l'on charge toute la liste, beaucoup trop long. |
|
Je reviens sur ce premier sujet car un doute m'assaille. Je ne suis pas sur que la solution de la liste avec autocomplétion résolve réellement le problème. Si c'est le cas, le problème de chargement de l'application délais + bug (deux problèmes en fait) ne sera pas résolu par l'implémentation d'une liste avec autocomplétion. Si c'est le cas, serait-il possible de tenter de corriger le fonctionnement actuel :
limiter le nombre d'information remontées par cette même requête pour réduire le temps d’exécution ??? Merci d'avance pour vos avis |
|
Voir #327 |
Bonjour,
Je me permets une demande ici car malgré mes recherches dans les fichiers du serveur, je ne trouve pas la réponse.
J'ai une liste taxonomique d'environ 3000 taxons utilisée par un programme.
Le comportement lors de l'ajout d'une observation semble bon (autocomplete) cependant, je ne peux rechercher et saisir que parmi les 100 premières occurrences de la liste. Lorsque je saisie des caractères du 101eme taxon, je n'ai plus de résultat.
Merci d'avance pour votre aide
gncitizen v 0.99-4
The text was updated successfully, but these errors were encountered: