Closed DonovanMaillard closed 1 year ago
L'implémentation actuelle qui permet de lister les valeurs possibles pour une nomenclature donnée filtrées selon le rang taxonomique remonte à septembre dernier en réponse à #169. Elle repose sur une requête SQL qui permet d'appliquer les filtres selon les règles suivantes :
Il manque du coup un DISTINCT
si jamais la même valeur est présente plusieurs fois selon le rang taxonomique.
Est ce que ces règles listés ci-dessus sont justes ou faut-il plutôt remonter uniquement les valeurs possibles qui correspondent précisément au rang taxonomique du taxon (et donc sans se soucier de la hiérarchie du rang taxonomique).
Exemple avec la nomenclature de type METH_DETERMIN
avec le rang taxonomique Animalia:Insectes
, où les valeurs des rangs taxonomiques du royaume Animalia
sont aussi remontées ainsi que celles non rattachées à un rang taxonomique en particulier :
_id | code | hierarchy | default_label | type_id | kingdom | group |
---|---|---|---|---|---|---|
343 | 4 | 106.004 | Analyse ADN de l'individu ou de ses restes | 106 | any | any |
342 | 3 | 106.003 | Analyse d’ADN environnemental | 106 | any | any |
351 | 2 | 106.002 | Autre méthode de détermination | 106 | any | any |
346 | 7 | 106.007 | Détermination informatique par un outil de reconnaissance automatique | 106 | Animalia | Insectes |
349 | 10 | 106.010 | Examen auditif avec transformation électronique | 106 | Animalia | Insectes |
348 | 9 | 106.009 | Examen auditif direct | 106 | Animalia | Insectes |
347 | 8 | 106.008 | Examen biométrique | 106 | Animalia | Insectes |
347 | 8 | 106.008 | Examen biométrique | 106 | Animalia | any |
350 | 11 | 106.011 | Examen des organes reproducteurs ou critères spécifiques en laboratoire | 106 | Animalia | any |
447 | 12 | 106.012 | Examen des organes reproducteurs ou critères spécifiques sur le terrain | 106 | Animalia | Insectes |
447 | 12 | 106.012 | Examen des organes reproducteurs ou critères spécifiques sur le terrain | 106 | Animalia | any |
450 | 15 | 106.015 | Examen des restes de l'individu sur photo ou vidéo | 106 | Animalia | Insectes |
450 | 15 | 106.015 | Examen des restes de l'individu sur photo ou vidéo | 106 | Animalia | any |
448 | 13 | 106.013 | Examen des restes de l’individu sous loupe ou microscope | 106 | Animalia | any |
451 | 16 | 106.016 | Examen des traces ou indices de présence sur photo ou vidéo | 106 | Animalia | Insectes |
451 | 16 | 106.016 | Examen des traces ou indices de présence sur photo ou vidéo | 106 | Animalia | any |
452 | 17 | 106.017 | Examen direct des traces ou indices de présence | 106 | Animalia | Insectes |
452 | 17 | 106.017 | Examen direct des traces ou indices de présence | 106 | Animalia | any |
456 | 21 | 106.021 | Examen visuel de l’individu en main | 106 | Animalia | Insectes |
456 | 21 | 106.021 | Examen visuel de l’individu en main | 106 | Animalia | any |
449 | 14 | 106.014 | Examen visuel des restes de l’individu | 106 | Animalia | Insectes |
449 | 14 | 106.014 | Examen visuel des restes de l’individu | 106 | Animalia | any |
454 | 19 | 106.019 | Examen visuel en collection | 106 | Animalia | any |
455 | 20 | 106.020 | Examen visuel sous loupe ou microscope | 106 | Animalia | any |
457 | 22 | 106.022 | Examen visuel sur photo ou vidéo | 106 | Animalia | Insectes |
457 | 22 | 106.022 | Examen visuel sur photo ou vidéo | 106 | Animalia | any |
453 | 18 | 106.018 | Examen visuel à distance | 106 | Animalia | Insectes |
453 | 18 | 106.018 | Examen visuel à distance | 106 | Animalia | any |
438 | 1 | 106.001 | Non renseigné | 106 | any | any |
Oui, il faut bien faire un distinct.
Côté GeoNature on le fait en une seul fois :
WHERE regne IN ("any", current_regne) AND groupe IN ("any", current_group)
: https://github.com/PnX-SI/Nomenclature-api-module/blob/master/src/pypnnomenclature/repository.py#L57-L63
(le distinct est fait tout seul par l'ORM)
Ce que je ne comprends pas, c'est pourquoi le comportement des listes de nomenclatures a changé lors de l'ajout de la fonctionnalité de sauvegarde des valeurs du relevé précédent ? 🤔
L'ancienne implémentation reposait sur le découplage entre l'application de synchronisation (qui n'existe plus) et "Occtax" basée sur des curseurs (approche performante mais assez structurante à l'usage car il faut passer par une phase de mapping pour le retraduire sous forme de classe du modèle). La nouvelle implémentation passe par un "ORM" qui facilite notamment le mapping avec les classes du modèle. Cette refonte remonte à septembre dernier et personne, moi le premier :) n'a remarqué cette petite régression.
Pour information, il reste encore des parties de "Occtax" dont les requêtes SQL s'appuient sur des curseurs, je pense notamment à la gestion des observateurs et des taxons. Ces deux parties peuvent potentiellement travailler avec beaucoup de données (notamment les taxons), l'approche curseur va encore perdurer encore un peu :).
À terme, tout passera par l'"ORM" (entre guillemets car ce n'est pas vraiment un ORM, mais plus une couche d'abstraction pour SQLite) et le ContentProvider
qui expose les données issues de GeoNature (à l'origine géré par l'application de synchronisation) deviendra obsolète.
Corrigé dans la version 2.6.1
Version de l'application
Version d'Occtax-mobile affectée par le bug : 2.6.0 Version de GeoNature utilisée : x
Terminal et Version Android
Marque et modèle du terminal : multiple Version d'Android : multiple
Description du bug et comportement attendu
Certains items de nomenclatures sont affichés 2 fois : méthodes de détemrination, d'observation etc. Il semble qu'il s'agisse des nomenclatures qu'on récupère en fait la liste de toutes les nomenclatures + en doublon celles qui correspondent réellement au taxon qu'on est en train de saisir. Au lieu de se limiter à ces dernières on les a donc en double...
Comment reproduire
Faire une saisie, et tenter de modifier une méthode d'observation ou de détermination par exemple.
Logs
aucun