-
Notifications
You must be signed in to change notification settings - Fork 4
-
Notifications
You must be signed in to change notification settings - Fork 4
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
Ne pas synchroniser les taxons à chaque synchro #133
Comments
Il y a déjà une notion de synchronisation périodique partielle (cf. https://github.com/PnX-SI/gn_mobile_core/tree/develop/datasync#parameters-description) via les paramètres Quant à la synchronisation des relevée, elle reste dissociée de la synchronisation des données locales, elle est juste lancée en même temps au démarrage de l'application si les conditions sont réunies (accès réseau notamment). |
Bonjour,
Ce qu'on prévoit de mettre en place cette année est la logique suivante, et elle permettra sans soucis un déploiement avec des listes sur mesure et des listes associées aux différents jeux de données, donc possiblement tout le taxref tel que tu l'as filtré pour du grand public @TheoLechemia :
De cette manière :
Il faudra qu'on revoit ce point que tu soulignes @sgrimault , j'avais retenu que les données essentielles intégraient les taxons, les nomenclatures, les datasets etc. Et que seules les données géographiques étaient "non essentielles". Le fonctionnement ci-dessus impliquera que JDD et taxons soient synchronisés en même temps, mais en effet pas forcément à chaque "post" des données saisies, et pas forcement que quand on récupère les données géographiques. A réfléchir quand on arrivera sur cette fonctionnalité... |
Merci pour ces éclaircissement.
Quand je saisi une observation puis que je la synchronise, la synchro me retélécharge toute la liste taxo et les unité géographique.
|
En fait ça fait 3.... un pour les données obligatoire (taxons, datasets, nomenclatures etc), un pour les unités géographiques bien plus lourdes, et un pour poster ses relevés terminés. A voir comment on peut faire ça sans avoir 50 boutons... |
QQ remarques et propositions
Idéalement la synchro doit être rapide. En l'état à chaque synchro, tout est rechargé en mode supprimer remplacer, donc de manière un peu brute. Forcément s'il y a beaucoup de donnée, c'est long à chaque synchro. Proposition. Autre piste, versionner ce qui peut l'être. Comme cette vue taxref ou tout autre donnée qui bouge peu (liste de taxons, observateurs, nomenclatures, JDD, ...) Le serveur pourrait par exemple produire des fichiers json versionnés chaque fois que modification de listes, observateurs, taxons, nomenclatures, JDD, correspondances JDDs-listes, etc. Faisabilité technique à creuser. |
Bonjour, Je rejoins l'avis de @gildeluermoz concernant le "versioning" (ou l'horodatage des données éligibles à la synchronisation), sachant que c'était déjà un sujet qui a été évoqué il y a quelque temps. Concernant la synchronisation, les attributs L'application garde localement la date de dernière synchronisation des données (pour notamment notifier l'utilisateur de la "fraicheur" des données présentes localement). Si on ajoute coté GeoNature deux attributs permettant de connaitre la date de création et de modification sur chaque objet éligible à la synchronisation (Observateurs, taxons, etc.) et qu'il est possible de filtrer ces objets lors des appels aux routes pour la synchronisation des données en fixant la date de dernière modification, alors on aura le workflow suivant :
Le bouton "Synchronize" peut garder son fonctionnement actuel avec la synchronisation fonctionnant avec le principe décrit ci-dessus en adressant tous les usages possibles (avec ou sans synchronisation automatique), avec une petite amélioration à prévoir, calquée sur le fonctionnement de la synchronisation des données : Sous forme de "worker" (tache de fond dédiée, avec les mêmes règles en prérequis : réseau disponible, niveau de batterie ok, etc.). |
Bilan : Les développements sont en cours avec le résultat attendu suivant :
En clair, les données seront réparties en 3 blocs (contre 2 aujourd'hui) :
|
…layed when synchronizing observation records
Dans la version 2.6.0, la synchronisation des relevés vers GeoNature a été dissociée de la mise à jour des données de référence depuis GeoNature (nomenclatures, JDD, taxons, couleurs des unités géographiques, observateurs). La mise à jour des données de référence est faite automatiquement tous les 7 jours (par défaut, modifiable), ou lancé par l'utilisateur si il le souhaité dans le nouveau menu latéral : La mise à jour des données de référence est faite dans un traitement parallèle, pour ne pas empêcher la saisie, le temps qu'elle soit terminée. Lors du premier lancement, une première synchronisation des données de référence est lancée automatiquement, et il n'est pas possible de créer un relevé tant que cette première synchro n'est pas terminée. Reste à voir pour faire évoluer la mise à jour des taxons, pour pouvoir synchroniser tout Taxref, nécessaire aux évolutions à venir de liste des taxons par JDD. |
Ajout d'une route renvoyant la version de Taxref et de sa date de dernière mise à jour : PnX-SI/TaxHub#394. Exemple : https://demo.geonature.fr/taxhub/api/taxref/version Il faut donc ajouter un paramètre côté mobile pour pouvoir indiquer la date de dernière mise à jour de Taxref et la comparer avec la date dans la propriété |
Cela concerne aussi bien les taxons (GET -> /api/taxref/allnamebylist/{taxref_list_id}) que les données relatives aux taxons (GET -> /api/synthese/color_taxon) ? |
C'est seulement pour la liste des taxons, qui ne bouge qu'une fois par an (à peu prêt) quand on met à jour la version de Taxref. Les couleurs de taxon peuvent changer très régulièrement dès qu'il y a de nouvelles observations quelque part. Mais ça me soulève une question. PS : D'ailleurs, j'ai dit une bêtise, pas besoin d'un paramètre coté mobile pour stocker la date de mise à jour. |
Merci pour ton retour, j'avais un petit doute si ça pouvait couvrir les données relatives de chaque taxon. |
…ng to GET -> /api/taxref/version
Type d'amélioration
Perfomances
Proposition
Je teste la possibilité de mettre tout taxref dans l'appli.. En enlevant tous les synonymes et en mettant uniquement les taxons de métropole on est à 143 000 taxons. ça ne me parait pas énorme donc je me dis que ça pourrait être un gros plus dans un le cas d'une utilisation plus grand public de l'appli.
Je sais qu'il y a une volonté de pouvoir charger plusieurs liste de taxons (en lien avec les JDD) dans les tuyaux, du coup ça va un peu dans le même sens, on va avoir une multiplication du nombre de taxons.
Je ne sais pas encore quelle est la meilleur solution, mais il me paraîtrait judicieux de dissocier la synchronisation montante (j'envoie une obs) et la synchronisation descendante (ou je récupère mes référentiels). Notamment la taxonomie, qui à priori n'évolue pas rapidement.
Synchronisation plus périodique ?
Bouton pour synchroniser uniquement la taxonomie ?
The text was updated successfully, but these errors were encountered: