Synchronisation des taxons terminée avec des erreurs #280
Comments
|
Oui c'est bizarre. |
|
C'est très certainement lié à un souci sur au moins un taxon lors de la synchronisation et comme on a supprimé tous les contrôles pour gagner en efficacité et en temps car on part du principe que les données sont (et doivent être) cohérentes coté GeoNature et donc coté APIs, mais ce n'est pas du tout le cas : Un taxon valide, c'est un taxon qui doit suivre les règles suivantes :
Les données additionnels à un taxon doit être rattachées à un taxon valide :
Pour que la synchronisation des taxons soit efficace et rapide, elle fonctionne par "paquets", c'est à dire qu'on fait appel en cascade à l'API Ce n'est pas la première fois que des soucis de synchronisation soient remontées et je pense que c'est un vrai souci que les APIs de Geonature et TaxHub ne puissent pas garantir la cohérence des données entre tous les appels. |
|
OK OK, faudrait voir si il y a des données incomplètes qui ont été ajoutées dans le Taxref du PNG. @aferchal, tu as ajouté un taxon sans nom_complet ? Ou autre champs non renseigné ? En effet, on utilise un Taxref de base, complet et de référence, mais il arrive que l'on doive ajouter quelques taxons manuellement dans ce référentiel, notamment dans les DOM, quand de nouvelles espèces sont découvertes, le temps qu'elles soient intégrées officiellement dans une nouvelle version de Taxref. En effet, depuis la version 2.7 d'Occtax-mobile, on charge seulement une fois (puis à chaque nouvelle version de Taxref) tout Taxref. Et pour que cela soit assez rapide, on a supprimé tous les contrôles qui étaient trop longs : #247 Je pense qu'il ne faut surtout pas remettre ces contrôles pour ne pas que la synchro de Taxref soit plus longue. De notre côté, on pourrait ajouter plus de contraintes sur l'API pour ne pas renvoyer des taxons incomplets. Mais pour nos outils, c'est pas forcément un problème qu'un taxon n'est pas de group_inpn, ou de règne, peut-être même de pas avoir de lb_nom ou de nom_complet. Mais on peut regarder pour ajouter des contraintes en plus directement au niveau de la BDD dans la table |
|
Ce qui est étonnant ce qu'il va chercher les données sur le taxhub de la recette de GN hébergé au BRGM et je n'y vais jamais. Je n'utilise pas non plus de données additionnelles. La seule intervention concerne la màj de TAXREF en v17, à voir ce qui a été fait |
|
Ah OK, alors si c'est une instance de recette où vous n'avez rien touché de spécial et un Taxref v17 brut, non enrichi, alors je vois pas le soucis. En effet, vous êtes bien en version 17 sur cette plateforme de recette : https://gngua.brgm-rec.fr/taxhub/api/taxref/version Je viens de tester une installation d'Occtax-mobile 2.7.1 et la connecter sur le serveur DEMO qui est aussi en Taxref 17 (https://demo.geonature.fr/geonature/api/taxhub/api/taxref/version) et ça a synchronisé sans soucis. Votre GeoNature est en 2.14.2, ce qui est compatible avec Occtax-mobile 2.7. Sinon, je ne vois pas d'où peut venir le soucis... |
|
J'ai testé avec la demo de GN. La synchro aboutit avec un msg d'erreur avec un écran qui reste ensuite blanc dans l'appli sur les observateurs et les jdd Log de synchro : Log de saisie : |
|
Ouais OK OK, toi aussi ça indique des nomenclatures par défaut qu'il trouve pas. Ma seule piste là est qu'il te reste des données liés à ton instance GeoNature et qu'en basculant sur le GeoNature de DEMO, ça coince car il mélange des données de ton instance et de celle de DEMO. Mais je n'en suis pas certain, je ne sais pas si @sgrimault aurait une autre piste ? |
|
Bonjour, |
|
@sgrimault, le soucis que tu indiques correspond au second test d'@aferchal en se connectant au serveur de DEMO ? Je pense que tu parles sur le serveur de DEMO, et j'ai moi aussi désormais le même soucis (Erreur de chargement des valeurs par défaut, listes des observateurs et des JDD vides), alors que je ne l'avais pas précédemment en testant sur ce même serveur. Et je ne comprends pas le soucis que tu indiques avec la nomenclature J'ai aussi le message d'erreur remonté par @aferchal sur le serveur DEMO : |
|
Bonjour @camillemonchicourt, Le souci coté relevé est que le champ Concernant la dernière erreur ( |
|
OK oui, mais là je suis connecté au serveur de démo, je n'ai aucune donnée en attente de synchro, et je ne peux pas créer de nouveaux relevé. |
|
Sur un portable vierge de toute install de GN mobile j'ai installé GN mobile en 2.7.0 connecté au serveur DEMO. Il va bien au bout de la synchro (avec qd meme une erreur sur areas) : J'ai bien la liste des observateurs et des jdd, je peux pointer l'obs mais j'ai la liste des taxons vides alors que j'ai choisi un jdd sur lequel il y a des taxons associés (test sur AGIR). Ci dessous le log correspondant. En cherchant par nom de taxon, pas mieux. |
|
OK OK. Merci pour ce retour. Cela semble me confirmer que :
Mais je ne comprends pas pourquoi cela fonctionnait et pourquoi y a un soucis désormais. Ni pourquoi il ne récupère pas tous les taxons, quitte à ignorer les couleurs de taxons qui posent soucis, et ainsi ne pas planter la synchro ? Et par ailleurs, il y a aussi un soucis similaire remonté sur #281, et là je ne sais pas si c'est lié au fait d'avoir switché d'une instance GeoNature à une autre ? |
|
Alors, pour le serveur DEMO, on a identifié et trouvé le soucis. On va tester vérifier que cela corrige bien le soucis du serveur de DEMO. Par contre, cela n'explique pas le soucis initial d'@aferchal de synchro des taxons avec un GeoNature 2.14 et un TaxHub 2.14. |
Version de l'application
Version d'Occtax-mobile affectée par le bug : 2.7.0 et 2.7.1
Version de GeoNature utilisée : 2.14.2
Version de TH : 1.14.2 (?) Instance du BRGM
Terminal et Version Android
Marque et modèle du terminal : Xcover 4
Version d'Android : 10
Description du bug et comportement attendu
La synchronisation n'aboutit pas sur les taxons (cf log). J'ai reduit le chiffre du page_size mais pas mieux
Logs
log.txt
settings_occtax.json
settings_occtax.json
The text was updated successfully, but these errors were encountered: