Refactorisation du module

Une refactorisation complète du module a été initiée par @bouttier en 2021. Elle est initiée dans la branche dédiée : https://github.com/PnX-SI/gn_module_import/compare/develop...refactor

Évolutions prévues et initiées

Packaging du module pour être installé avec pip
Gestion des versions du schéma de BDD avec alembic
Corrections dans les modèles, ajout de relationships manquantes
Ajout de tests unitaires
Évolution de l’API vers les bonnes pratiques REST
Adaptation du frontend en conséquence
Ajout de typage sur le frontend
- Modèles TypeScript correspondant aux modèles Python
Suppression d’un grande nombre de requêtes SQL au profit de l’ORM
Refonte des contrôles s’exécutant sur la DataFrame
- Isolation du code de contrôle permettant de le tester
- Factorisation de la gestion des erreurs
Simplification de la logique du frontend en supprimant les données par étape au profit de l’utilisation des modèles Python.

Le travail doit continuer pour faire :

Refactorisation du code et sécurité (injection de codes)
Ajout de tests unitaires
Ajout détection automatique de l'encodage des fichiers importés
Amélioration de la gestion des mappings/correspondances des modèles de fichiers d'import

Détail des taches prévues, à spécifier :

1. Interdire l'import de données dont la date d'observation est antérieure à la date du jour

A l'heure actuelle des données dont la date d'observation est ultérieure à la fate du jour peuvent être iportées sans problème dans GeoNature. Actuellement il n'existe que 2 contrôles sur les dates au niveau du module d'import :

date_max not provided
date_min > date_max

Ajouter les contrôles à l'import vérifiant que date_min et date_max sont inférieures ou égales à date du jour.

date_min ≤ date_jour_systeme
date_max ≤ date_jour_systeme En cas d'erreurs les données sont considérées comme invalides.

Ajouter Un warning à l'import vérifiant que date_min et date_max sont inférieures ou égales à 1900 > l'info est remontée dans le rapport d'erreur mais les données sont considérées comme valides.

2. Choix du délimiteur dans les paramètres de chargement du fichier

Même principe que pour l’encodage : après upload du fichier, le délimiteur est auto-détecté. À l’étape suivante, le délimiteur est pré-sélectionné sur la valeur auto-détecté mais l’utilisateur peut modifier ce choix.

3. Rendre scalable le check des UUID déjà dans la synthèse

4. Rendre paramétrable le check de l'unicité de U_id_sinp sur l'ensemble de la synthèse ou par jeu de donné

5. Vérification du référentiel cd_nom

Vérifier que les cd_nom sont dans le référentiel TaxRef

6. Vérification du référentiel cd_hab

Vérifier que les cd_nom sont dans le référentiel HabRef

7. Entity source pk : vérifier les doublons (DUPLICATE_ENTITY_SOURCE_PK)

8. ID Digitizer: récupérer id à partir MTD INPN

L’id_digitizer est une FK vers id_role. Dans le cas où l’utilisateur n’existe pas dans la table utilisateurs.t_roles (typiquement l’utilisateur ne s’est jamais connecté à DEPOBIO), il faut importer l’utilisateur depuis MTD.

Si l’utilisateur n’a pas pu être récupérer depuis MTD => erreur sur la ligne de l’import : digitizer inconnu

CM : Si un utilisateur ne s'est jamais connecté à DEPOBIO, je ne vois pas comment il pourrait être digitizer ? JP : Ce cas d'usage me est possible sur nos instances. ex. L'utilisateur a créé des MTD sur l'INPN mais ne s'est pas encore connecte a GeoNature. Entre temps l'administrateur est connecté et toutes les MTD sont récupérées de l'INPN . Nous avons mis en place un CRON automatique de récupération de toutes les MTD de la plateforme.

9. Génération des altitudes

Voir comment c’est fait actuellement.

À priori :

case à coché « générer les altitudes manquantes »
lorsque l’altitude n’est pas renseigné dans le fichier source, on prend la géométrie, et on en déduie l’altitude min et l’altitude max à partir du MNT présent dans le ref_geo (fait par exemple dans OccTax)
prévoir le cas où le MNT n’est pas présent (altitude non généré, mais ça ne doit pas planter - on peut toutefois logguer le manque du MNT pour l’admin)

10. Reporter le nom original des colonnes dans les erreurs

Dans le rapport d’erreur, on veut le nom de la colonne du CSV pour que l’utilisateur soit en mesure de retrouver son erreur.

Dans l’objet Import, il y a un tableau d’association colonne PostgreSQL / colonne CSV, utile pour les conversions.

11. Vérifier URL de digital_proof

12. Vérifier les lignes dupliquées (DUPLICATE_ROWS)

13. Ajout du support du format geojson

En v1: le geojson était convertie en CSV. Sans doute mieux d’importer directement le geojson dans la table. À voir s’il est possible de présélectionner le champs de géométrie à l’étape de mapping des champs.

14. Limitation de la taille du fichier

15. Supprimer goodtables

Vérifier la validité du fichier CSV lors de l’import en base via panda.

16. Tests unitaires > Permissions sur JDD

Vérifier qu’on import sur un JDD sur lequel on a les droits. Peut-être déjà fait, mais :

test à rajouter
en 2.9, ajout de TDatasets.query.filter_by_readable() qui implémente la logique de check cruved

17. Tests Code maille

Test unitaire sur la validité de code maille.

18. Tests Code commune

Test unitaire sur la validité de code commune.

19. Tests Code département

Test unitaire sur la validité de code département.

20. Gérer différent types de code maille

Utiliser les codes long plutôt que les courts.
Actuellement on utilise les courts mais du coup on force les mailles 5×5 (je crois) car les codes courts sont en conflit entre les différents types de mailles.
Vérifier que cela fonctionne avec les mailles européennes.

21. Gestion de TypeInfoGeo

Le champs TypeInfoGeo sert à indiquer, lorsque plusieurs informations géographique sont attachées à une observation, quelle est l’information géographique de référence (on doit toujours avoir une information géographique avec TypeInfoGeo=géolocalisation, les autres informations géographique ont donc TypeInfoGeo=rattachement).

GeoNature ne gère qu’une seule information géographique par observation. Cette information géographique est donc nécessairement de type géolocalisation. Dans ce cadre, ce champs n’a pas lieu d’être dans GeoNature. Il peut donc être retiré du module d’import.

Cependant, une autre information est utile : DEE_FLOUTAGE, permettant d’indiquer s’il s’agit d’une information géographique précise ou dégradé. Il faudrait rajouter la possibilité d’indiquer cette information dans le module d’import. Pas de check associé à ce champs (toutes les combinaisons sont possible, geom de type point avec FLOUTAGE=OUI (typiquement centroïde), geom de type commune avec FLOUTAGE=NON - malheuresement la commune peut être l’information la plus précise que l’on a).

22. [Backend] Suppression table après import

23. [Backend] Suppression du schéma archives

24. [Backend] Gestion des erreurs à chaque étapes

25 [Backend] Création d’un n° unique de requête, affichage dans les erreurs, et ajout d’un tag dans sentry

26. [Backend] Migration alembic pour 1.1.x => 2.0.0

27. [Backend] Import asynchrone

A découper et spécifier
Avoir un worker dans GeoNature
Module puisse créer des taches
Notification de fin d'import au front
Notification de fin d'import par mail

28. [Frontend] Gestion des mappings

API OK, reste de la gestion en front, surtout côté valeurs

29. [Frontend] Gestion des steps : suppression du field « step », détermination du step à partir des données de l’import

30. [Frontend] Liste d’import : nettoyage champs à partir du modèle d'import (import, nom, encodage)

31. [Frontend] Gestion reprise de l’import

https://github.com/PnX-SI/gn_module_import/blob/refactor/frontend/app/components/import_process/import-process.resolver.ts

32. [Frontend] Gestion de l’asynchrone

33. Documentation

Mise à niveau de la documentation technique GeoNature

34. Pouvoir spécifier dans la configuration la liste des checks à exécuter

Plutôt que de rajouter une option dans la conf pour chaque check que l’on souhaite rendre optionnel, définir un paramètre qui liste les checks à appliquer. Il devient alors facile de pouvoir désactiver des checks en les retirant de cette liste.

Idéalement, cette liste doit permettre de rajouter des checks non prévu (test spécifique à mon instance).

Deux idées pour cela :

la liste contient des chemin python de fonction de check à importer
la liste contient des noms de check textuel, les checks additionnels étant auto-détectés à partir d’entry_point

Pour chaque check, pouvoir indiquer si le check est bloquant ou non (error vs warning)

35. Création table de données d'import dédiée

36. [Frontend] Composant générique d'affichage des erreurs

Handler sur les 500 qui appelle le toaster par exemple

Merci pour cette info. Quelques premiers retours en attendant d'avoir des détails pour les différents points qui le nécessiteraient :

5 Vérification du référentiel cd_nom : déjà fait et fonctionnel (https://github.com/PnX-SI/gn_module_import/blob/6e7561ee5de223488d329157c3418ee887368ff1/backend/transform/check_referential.py#L37)
6 Vérification du référentiel cd_hab : à vérifier si fonctionnel, mais déjà au moins initié dans le code
7 Entity source pk : vérifier les doublons : ça avait été discuté lors de la création du module et il nous avait semblé que ça peut poser soucis dans le cas de plusieurs partenaires travaillant sur un même jeu de données, si chacun verse des données depuis sa base -> les identifiants peuvent ne pas être uniques dans un import "compilé" par le fournisseur des données, qui peut ne pas être le producteur.
9 Génération des altitudes - Voir comment c’est fait actuellement - case à coché « générer les altitudes manquantes » : Non, actuellement si on calcule les altitudes avec la checkbox, on calcule pour toutes les données par cohérence/homogénéité au sein de l'import. Discutable en effet...
22 [Backend] Suppression table après import : nécessiterait d'être discuté, ce fonctionnement actuel avait été choisi en concertation et était souhaité. Sauf si "remplacé" par un nouveau stockage avec le point 35?
23 [Backend] Suppression du schéma archives : idem, c'est un choix concerté à l'origine pour garder la trace des dépôts avant transformation des données dans le format SINP
24 [Backend] Gestion des erreurs à chaque étapes : c'était le fonctionnement initial, mais qui a été changé pour un seul controle à l'issue des mappings. Ce nouveau fonctionnement permet de ne pas stopper ou faire attendre l'utilisateur à chaque étape de son import
28 [Frontend] Gestion des mappings : à préciser au niveau des attentes, mais différents échanges ont déjà eu lieu sans consensus actuellement

A voir si des échanges peuvent être faits points par points quand ça dépasse le simple volet technique

Suite aux échanges :

7 Entity source pk : vérifier les doublons / OK pour ajouter ce contrôle mais le rendre activable ou non, comme tout (ou la plupart ?) des contrôles si il peut poser des soucis dans certains cas
9 Génération des altitudes : Plutôt ne calculer que quand la donnée n'est pas fournie. Si on veut calculer toutes les altitudes d'un fichier fourni, alors on coche la case et on ne mappe pas la colonne "altitude"
22 [Backend] Suppression table après import / Volonté de supprimer les tables intermédiaires temporaires de transformation quand l'import est terminé. Néanmoins cela pose la question de comment on exporte les données invalides, comment on génère le rapport d'erreur. A voir aussi si on continue à permettre à un administrateur de BDD de travailler en SQL sur sa table intermédiaire d'import.
23 [Backend] Suppression du schéma archives / Stocker le fichier source en binaire permet d'analyser le fichier source pour en déduire le délimiteur et l'encodage automatiquement. Si on stocke le binaire, cela fait doublon de stocker en plus le fichier source dans une table dédiée. Cela pose la question plus globale du principe de GeoNature d'avoir un lien entre une donnée dans la Synthèse et sa source. Besoin : Pouvoir revenir aux données sources sous une forme ou une autre (table ou CSV) et pouvoir exporter les données en erreur et accéder au rapport d'erreur
28 [Frontend] Gestion des mappings / Inverser le sens de mapping au niveau des nomenclatures. Chaque sens a des avantages et inconvénients

28 [Frontend] Gestion des mappings / Inverser le sens de mapping au niveau des nomenclatures. Chaque sens a des avantages et inconvénients

A ce stade le changement a été développé et implémenté dans la branche de refonte. Le changement sera laissé pour la release, avec ses avantages et ses inconvénients. D'une manière générale, l'amélioration de l'ergonomie viendra à terme du fait que le module fasse intelligemment des propositions de mapping pertinentes quand on crée un nouveau mapping , et non pas du sens de l'affichage...

Nouveau modèle de données pour les mappings. Les mappings sont stockés entièrement dans les champs t_imports.fieldmapping et t_imports.contentmapping. Le modèle t_mappings correspond exclusivement aux modèles d’import. Les tables t_contentmappings et t_fieldmappings permettent de stocker les associations des modèles dans le champs values. Les champs t_fieldmappings.values / t_imports.fieldmapping sont de type HSTORE, il s’agit d’un tableau d’association de la forme suivante :

{
    champs de destination ⇒ champs source
}

Les champs t_contentmappings.values / t_imports.contentmapping sont de type JSON, le JSON à la forme suivante :

{
    mnemonique du type de nomenclature ⇒ {
        valeur source ⇒ cd_nomenclature de la nomenclature de destination
    }
}

Les modèles sont modifiables depuis Flask-Admin. Une validation vérifie le bon formatage du JSON, l’existence des mnémonique / des cd_nomenclature, ainsi que des champs de destination pour les correspondances de champs.

Top, merci pour cette amélioration sur les mappings, dissocier les modèles et les mappings réellement utilisés était essentiel !

Pour la t_import, tu as laissé pour le moment le champ import_table.

Veux tu qu'on ré-échange à l'occasion pour modifier le stockage des données sources ? je proposais quelque chose comme :

Une table "t_import_table" ou "t_source_data" par exemple, avec un champs id_import, un champ json qui contient la donnée source, et un champs qui répertorie les erreurs . A voir si besoin d'autre chose.

Ca peut faire une table un peu complexe à l'arrivée, mais ca évite de multiplier les tables dans ce schéma (un soucis dans certaines instances) et ça permet de travailler/récupérer/retélécharger les données invalides pour conserver cette fonctionnalité.

Nouvelle proposition :

une table t_import comme actuellement
une table t_import_data avec une FK vers t_import.id_import ainsi que toutes les colonnes de la synthèse × 2 : un jeu de colonne « source » et un jeu de colonne « destination »

L’utilisateur téléverse son fichier, choisie l’encodage, le délimiteur, etc. À ce moment là, on lit uniquement la première ligne du fichier CSV de manière à lire les colonnes du fichier ; celles-ci sont stocké dans t_import.columns. Les données ne sont pas encore lue !

On passe aux correspondances de champs. Pour cela, on lit les colonnes source du CSV depuis t_import.columns et les colonnes de destination depuis dict_fields comme actuellement. Lorsque les correspondances de champs sont validés, les données du fichier CSV sont chargé dans la table t_import_data, en plaçant les données dans le jeu de colonnes « source ». Cette table contient les données de tous les imports, mais la FK t_import.id_import permet de retrouver les données de notre import uniquement.

On passe aux correspondance des valeurs. On utilise la table t_import_data pour retrouver les valeurs disponibles à l’import. Après validation est lancé l’étape de transformation qui va placé dans le jeu de colonne de destination les valeurs après transformation.

On peut ici effectuer en SQL toutes les modifications des données que l’on souhaite. On utilisera simplement des noms de colonnes qui correspondent aux colonnes de la synthèse plutôt qu’au colonne du fichier CSV (c’est à mon avis même plus simple).

Puis on passe à l’étape d’import des données dans la synthèse, qui est alors extrêmement simple.

Hmmm un peu gymnastique pour retrouver là dedans quelque chose qui ressemble au fichier source (on perd les infos qu'on ne rattache à rien (mais peu importe on a choisi de les ignorer), on n'a plus notre nom de colonne donc on doit retourner voir la correspondance.... Je pense que dans la pratique, retourner sur la donnée source sera "complexe" ou moins intuitif mais faisble. En faisant ca, on perd l'a donnée des champs non mappés (donc si on veut modifier ou compléter le mapping, on a toujours le nom de la colonne mais on a pu la donnée ?.

A voir aussi comment se traite le champs json additionnal_data de la syntèhse (plusieurs valeurs de plusieurs champs en entrée). Pourquoi pas, je suis pas sur de tout voir très clair tout de suite mais je suis pas fermé à cette facon de faire non plus.

Petite question quand même. Si on stocke le contenu du fichier source dans un champs binaire. Il existe des fonctions (ou une possibilité de faire une fonction) qui permette de "remonter" une table du fichier source à partir du binaire ?

On perd les colonnes qu’on ne rattache à rien : en effet. On peut peut-être charger ces données dans un champs JSON, mais alors uniquement ces données. En effet, la manipulation d’un champs JSON est d’une part moins performant, et d’autre part plus complexe.
On n’a plus la structure source : est-ce réellement important ? On a procédé à une correspondance des champs justement pour s’affranchir d’une structure spécifique à un fichier CSV pour se diriger vers la structure standardisé de GeoNature. J’ai l’impression qu’on a tout à y gagner : nous n’avons justement plus à nous poser la question de savoir ce que peut bien contenir une colonne possédant un nom non standard, ou comment peut bien se nommer la colonne contenant telle ou telle information.
Il semble assez naturel de traiter le champs additionnal_data comme un champs JSON à l’image de celui présent dans la synthèse. Les champs source y seront placé directement.
Oui on peut « remonter » une table à partir du fichier source actuellement, mais l’idée serait quand même de ne plus avoir cette nécessité pour éviter de polluer les schémas avec de multiples tables aux structures multiples. Peux-tu argumenter le besoin d’avoir vraiment une table correspondant aux données source ? Pour voir si le compromis proposé est vraiment si loin du besoin. De mon côté je vais éventuellement regarder si on peut pas même faire une fonction SQL pour ça.

On perd les colonnes qu’on ne rattache à rien : en effet

Donc on aurait certains champs en json, certains réorganisés selon le mapping au format synthèse ... pourquoi pas

On n’a plus la structure source : est réellement important ?

Dans la base non, je pense que c'est surtout une question d'habitude quand on travaille sur les données, et encore une fois pour une manip qu'on fait quand meme qu'occasionnellement de remonter à la source... pas bloquant en effet, mais c'est un choix de se dire qu'on stocke uniquement un format transformé

pour le json additionnal_data ok donc le champs source et cible seraient sous le même format, et pas au format source (mais ni genant ni d'autres solutions avec la possibilité que tu proposes)

Le besoin de retrouver d'une manière ou d'une autre le fichier source est intéressant et souhaité dès la conception du module, pour pouvoir remonter au fournisseur de données ce qu'il nous a transmises ou non à un instant t par exemple, pour qu'il puisse nous transmettre un différentiel, des données à jour etc, ou pour qu'on puisse revenir nous-mêmes sur le mapping qu'on a fait, voir si on a des choses à corriger ou améliorer pour mieux traduire les données source qu'on a reçues vers le format SINP. Notamment quand il y a des changements de référentiels ou de nouveaux champs, qui dans certains cas peuvent être alimentés depuis la source et plus depuis les DEE qu'on en a tirées.

En fait pour résumer les besoins (à mon sens) liés à cette question :

Modifier/Compléter les données en SQL est utile à mon avis au cours de l'import uniquement (calculer un cd_nom, splitter des champs etc) entre l'upload et l'import en synthèse
Stocker sous un format ou un autre l'info brute sur laquelle on peut refaire une copie du fichier source (en sql ou non) a du sens pour revenir sur des données qui nous ont été transmises
Avoir un format de stockage qui nous permette, une fois l'import terminé, d'exporter les données invalides comme vu plus haut pour garder cette fonctionnalité

Du coup entre ce que tu proposes ici ou un stockage binaire qui conserve ces possibilités (donc une table d'import dans la même logique qu'aujourd'hui, mais supprimée après l'import) sont toutes les deux possibles. A voir ce qui est le plus propre. Le choix entre les deux doit surtout être un choix technique lié aux performances à priori...

DEE ?

Sinon l’ensemble des contraintes que tu as soulevés sont à mon sens compatible avec la solution proposée. Tout en étant plus performant et plus propre.

Pour préciser le processus :

correspondance des champs → chargement des données source dans les colonnes « source » à partir du fichier CSV
correspondance des nomenclatures → chargement des données dans les colonnes « destination »
manipulation manuel des données dans les colonnes « destination »
copie des colonnes « destination » dans la synthèse

Téléchargement des données invalides : à partir du CSV source, et non de la table t_imports_data qui ne contient pas l’entièreté des données du fichier CSV (du moins pas directement) (on utilise tous de même la table t_imports_data pour avoir les numéros des lignes erroné à renvoyer à l’utilisateur).

La synthèse est re-calculable : à partir du fichier csv source et des 2 mappings, on peut re-généré les données des colonnes « destination ». Est-ce donc utile de garder ces données à la fin du processus d’import ? Non pou les colonnes « source », oui pour les colonnes « destination » si les données ont été manuellement modifié, les garde-t-on ?

Ok, merci pour ces échanges et précisions.

De ma compréhension, si on va vers cela, on n'a pas besoin de garder les données intermédiaires après l'import. Seulement les données sources brutes et la possibilité d'exporter les données invalides.

On a 4 fois les données :

Le fichier CSV source stocké en binaire
Les colonnes « source » : données source non touché, mais que les colonnes sélectionnées à l’étape de correspondance des champs
Les colonnes « destination » : données transformées, identique à ce qu’on trouve dans la synthèse, avec les lignes en erreurs en plus
La synthèse

⇒ Il apparaît inutile de garder les colonnes « source » et « destination » à la fin du processus d’import.

Se pose aussi la question de l’utilité d’avoir 2 fois les colonnes de la synthèse. Pour les nomenclatures, c’est nécessaire car on les transformes après l’étape de correspondance des valeurs. En revanche, cela apparaît inutile pour les autres colonnes. Ceci dit, on pourra trouver dans les colonnes dites « source » des colonnes qui ne sont pas dans la synthèse, celles référencés dans dict_fields avec synthese_field=False : codecommune, codemaille, longitude, hour_min, … qui servent à alimenter les colonnes de la synthèse après transformation.

DEE

Données élémentaires d'échanges selon les termes du SINP. En clair, les données de synthèse.

Ceci dit, on pourra trouver dans les colonnes dites « source » des colonnes qui ne sont pas dans la synthèse

Oui, on peut notamment avoir un champs qu'on ne mappe avec rien, qu'on manipule pour le splitter, et utiliser ces champs calculés pour l'import. Celà dit, on peut toujours avoir comme tu disais un json qui contient tous les champs non mappés derrière les champs de synthèse en double.

Si on a stocké les mappings, qu'on peut les télécharger, les réimporter, qu'on peut récupérer le fichier source. On peut à mon sens ne pas garder les lignes des imports terminés dans la table t_import_data ... On perdra certes les infos calculées, mais ça reste un cas d'usage qui , même si on souhaite le conserver, ne doit pas plomber tout le fonctionnement normal du module.

Du coup :

correspondance des champs → chargement des données source dans les colonnes « source » à partir du fichier CSV + stockage des autres champs dans un json
correspondance des nomenclatures → chargement des données dans les colonnes « destination »
manipulation manuel des données dans les colonnes « destination » pouvant s'appuyer sur le json des champs non mappés
stockage des identifiants des lignes invalides (dans t_imports par exemple?) pour en permettre l'export ?
copie des colonnes « destination » dans la synthèse
suppression des lignes associées à cet id_import dans la table t_import_data

Pour l'export des données invalides, s'il faut reconstituer une table à partir du binaire et aller piocher dedans les lignes en erreur, on peut imaginer d'avoir comme pour le module export un envoi de mail quand le fichier est dispo.

De cette manière :

Une seule table t_imort_data pour tous les imports en cours. Nettoyée quand les imports sont terminés pour qu'elle soit facile à exploiter et ne pas garder 4 fois les memes données à terme
Un stockage binaire du fichier source
Un stockage des données en synthèse
Les données restent modifiables en base lors du processus
on peut exporter les données invalides... ca semble cocher toutes les cases.

Pour la pertinence d'avoir tous les champs de la synthèse ou non en double... : "En revanche, cela apparaît inutile pour les autres colonnes."

On peut imaginer d'avoir en fait tous les champs de la dict_field en guise de source
Tous les champs synthèse en guise de destination
oui, 2 champs source (date + heure) peuvent aliemnter un seul champs cible.
En faisant ça on conserve toutes les possibilités d'alimenter la synthèse et de transformer/calculer les données "à volonté", de voir en base ce qui sera poussé en synthèse à partir de nos différents choix de mappings etc. Même si c'est des champs geom par exemple (permettre une reprojection d'une partie des données) ou des champs dates (une partie des dates mal interprétées ou à modifier (on a des cas avec une seule date + un champs "précision de la date ±15j : on peut faire date min = date-15 et date max=date+15). Surtout si la table est vidée des lignes en question après import. Pour ce qui concerne ces calculs qui seront "perdus" par le module... si on est en mesure d'aller modifier les données en base lors du traitement, à chacun de s'organiser pour avoir des fonctions ou des scripts qui permettent de reproduire les calculs.

La refonte du module est bien avancée et fonctionnelle. Voici les évolutions réalisées :

Évolutions techniques

Packaging du module
Gestion de la BDD du module avec Alembic
Suppression du code SQL au profit de l’utilisation de l’ORM.
Suppression des try/expect générique ; les imports ne passent plus en erreur, mais l’erreur est collectée dans les logs de GeoNature et dans sentry et il est permit à l’utilisateur de réessayer en reprenant là où il en était.
Nombreuses corrections de bugs par l’écriture de code plus robuste.
Ajout de tests unitaires (couverture de code à 91%)
Refonte des modèles d’imports :
- Gestion correcte des permissions, ajout, modification, suppression …
- Les correspondances sont sauvegardée directement dans l’import indépendamment du modèle, résolvant ainsi les soucis liés à la reprise d’un import dont le modèle utilisé a été modifié, et supprimant le recours aux modèles temporaires.
- Les correspondances de champs / de nomenclatures sont stoquées au format JSON
- Correspondances de champs : { champs de destination => champs source } Note : Ce format permet d’associer un champs source à plusieurs champs de destination.
- Correspondances de nomenclatures : { mnémonique type de nomenclature => { valeur source => code nomenclature de destination } } Note : Ce format permet d’associer plusieurs valeurs sources à une même nomenclature de destination.
Asynchrone : utilisation d’un worker Celery permettant d’exécuter un seul contrôle / import à la fois (évite l’effondrement du serveur lors de plusieurs imports).
Stockage du fichier source au format binaire dans une colonne de l’import. Cela rend inutile les tables d’archives qui sont supprimées ; les données sont préalablement migrées au format binaire.
Suppression des tables transitoires créées à partir de la structure des fichiers CSV au profit d’une unique table transitoire. Les données sont chargées depuis le fichier source après l’étape de correspondance des champs.
La table transitoire contient un jeu de colonnes source et un jeu de colonnes destination ; les transformations sont refondues sur cette base, apportant un gain de simplification et de robustesse.
Les contrôles python fondé sur une dataframe panda ont été réduit et convertie en SQL lorsque possible pour de meilleur performance.

Évolutions fonctionnelles

Pagination de la liste des imports côté serveur pour optimiser son chargement et affichage quand on a de nombreux imports
Vérification des permissions sur le JDD.
Découpage de l’étape de téléversement et paramétrages en 2 étapes distincts :
- Téléversement du fichier
- Sélection des paramètres du fichier :
- Format : CSV uniquement (le support du GeoJSON est à rétablir)
- Encodage : une liste configurable d’encodage est proposé avec l’encodage auto-détecté pré-sélectionné
- Séparateur : une liste configurable de séparateur est proposé avec le séparateur auto-détecté pré-sélectionné
- SRID (pas d’évolution)
Le formulaire de correspondances des nomenclatures a été inversé : pour chaque nomenclature associée lors de la correspondance des champs sont affichées les valeurs source présente dans le fichier, avec un select permettant de choisir la nomenclature de destination. Il reste possible d’associer plusieurs champs source à une même nomenclature de destination, et ce sans multi-select.
Gestion des modèles dans l’interface d’administration de GeoNature,
Possibilité de reprendre un import à n’importe quelle étape, y compris lorsque celui-ci est terminé (permettant de mettre à jour des données déjà importées dans la synthèse).
Contrôle et import des données effectuées en asynchrone, peu importe le nombre de lignes du fichier.
Notification par email de la fin des opérations asynchrones à rétablir.
La dernière étape est dynamique, et affiche, suivant l’état de l’import :
- Un bouton de lancement des contrôles;
- Une barre de progression des contrôles;
- La prévisualisation des données contrôlées et le bouton de lancement de l’import;
- Un spinner d’attente pendant l’import;
- Un rapport d’import.
Suppression du TYP_INFO_GEO [https://github.com/PnX-SI/gn_module_import/issues/271]
Utilisation des codes mailles longs [https://github.com/PnX-SI/gn_module_import/issues/218]

Permissions

Modèles d’import (module "IMPORT", objet "MAPPING") Les modèles possèdent un ou plusieurs propriétaires, par défaut leur créateur, qui servent au calcul de la porté des permissions.
- Modèles accessibles à l’utilisation : droit R (1 minimum) + modèles publics
- C : Possibilité de créer un modèle
- U : Possibilité de modifier un modèle, selon la portée
- D : Possibilité de supprimer un modèle d'import, selon la portée
Import (module "IMPORT", objet "IMPORT") Les imports possèdent un ou plusieurs propriétaires, par défaut leur créateur, qui servent au calcul de la porté des permissions.
- R : Accès aux imports, aux rapports d’erreurs, aux données invalides
- C : Création d’import et modification des imports existants
- D : Suppression des imports

Processus

J'ai un R d'au moins 1 sur le module Import : J'accède au module et je vois les imports en fonction de mon R sur l'objet "IMPORT"
J'ai un C d'au moins 1 sur le module Import, je peux créer un Import, ou terminer un import auquel j'ai accès
J'ai au moins un JDD actif associé au module Import
Je créé un nouvel Import. Le C sur le module Import permet de lister mes JDD actifs et associés au module Import, ceux de mon organisme ou tous les JDD actifs associés au module Import
Je choisis le JDD auquel je veux associer les données à importer
Etape 1 : J'uploade mon fichier CSV (GeoJSON n'est plus disponible dans la v2 pour le moment). Le contenu du CSV est stocké en binaire dans la table des imports (gn_imports.t_imports.source_file). Cela permet d'analyser le fichier (encodage, séparateur...) et à terme de télécharger les données sources (non disponible pour le moment).
Etape 2 : L'encodage, le format et le séparateur du fichier sont auto-détectés. Je peux les modifier si je le souhaite. Je renseigne le SRID parmi les SRID disponibles dans la configuration du module.
Etape 3 : Je choisis un modèle d'Import existant et/ou je mets en correspondance les champs du fichier source avec ceux de la Synthèse de GeoNature. Les modèles d'import listés dépendent des permissions sur l'objet "MAPPING". Le contenu du champs gn_imports.t_imports.source_file est lu pour lister les champs du fichier source.
Si je choisis un modèle et que je mappe un nouveau champs, ou une valeur différente pour un champs, je peux modifier le modèle existant, en créer un nouveau ou ne sauvegarder ces modifications dans aucun modèle. Si j'ai mappé une valeur source différente sur un champs déjà présent dans le modèle, il est écrasé par la nouvelle valeur si je mets à jour le modèle. Actuellement un champs de destination ne peut avoir qu'un seul champs source. Par contre un champs source peut avoir plusieurs champs de destination (date > date_min et date > date_max, par exemple).
Les correspondances des champs sont stockées dans tous les cas en json dans la table gn_imports.t_imports.field_mapping. Cela permet de pouvoir reprendre les correspondances d'un import, même si le modèle a été modifié entre temps.
Quand on valide l'étape 3, les données sources des champs mappés sont chargées dans la table d'import temporaire (gn_imports.t_imports_synthese) avec une colonne pour la valeur de la source et une pour la valeur de destination. Cela permet à l'application de faire des traitements de transformation et de contrôle sur les données. Les données sources dans des champs non mappées sont importées dans un champs json de cette table (extra_fields)
Etape 4 : Les valeurs sont déterminées à partir du contenu de la table gn_imports.t_imports_synthese. Une nomenclature de destination peut avoir plusieurs valeurs source. Pour chaque nomenclature on liste les valeurs trouvées dans le fichier source et on propose de les associer aux valeurs des nomenclatures présentes dans GeoNature. Si le fichier source comprend des lignes vides, on propose en plus de mapper le cas "Pas de valeur". Le reste est similaire à l'étape 3
Etape 5 : Il est proposé à l'utilisateur de lancer les contrôles. Ceux-ci sont exécutés en asynchrone dans tous les cas, et une barre de progression est affichée à l'utilisateur. Quand les contrôles sont terminés, le nombre d'erreurs est affiché, ainsi qu'une carte de l'étendue géographique des données et un tableau d'aperçu des données telles qu'elles seront importées. Si il y a des erreurs, l'utilisateur peut télécharger le fichier des données sources invalides. Elles sont récupérées dans la table gn_imports.t_imports.source_file en ne prenant que les lignes qui ont une erreur, en se basant sur les données qui ont le champs valid=false dans gn_imports.t_imports_synthese L'utilisateur peut alors lancer l'import des données dans la Synthèse. Elles sont lancée en asynchrone dans tous les cas, et un spinenr de chargement est affiché tant que l'import est en cours. Si d'autres imports sont en cours, le mécanisme asynchrone gère un système de queue pour les faire les uns après les autres et ne pas saturer le serveur.
Il est possible de reprendre et modifier un import que celui-ci soit terminé ou non. Il est aussi possible d'uploader un nouveau fichier pour un import existant. Si l'import avait été terminé, alors les données du nouveau fichier uploadé seront intégrées en remplacement de celles importées précédemment.
Une fois les données importées, les données sont supprimées de la table temporaire (gn_imports.t_imports_synthese)
Administration des modèles : Depuis le module ADMIN de GeoNature, il est possible de lister, afficher et modifier les modèles d'import.

Refonte réalisée dans la version 2.0.0 avec donc une reprise de fond de tout le code, l'ajout de tests automatisés (couvrant 91% du code backend).

La migration Alembic de la version 1.x à 2.x permet d'appliquer automatiquement les évolutions importantes de la BDD, dont la suppression du schéma d'archive (après avoir récupérer les données sources pour les importer dans le champs gn_imports.t_imports.source_file) ainsi que les tables intermédiaires des imports réalisés en v1.

Reste quelques régressions à traiter par ailleurs :

Import des GeoJSON
Notification par email de la fin des opérations asynchrones (contrôles et import des données)
Tag des imports à corriger (Nouveauté 1.2.0)
Alimentation des champs additionnels avec plusieurs colonnes (Nouveauté 1.2.0)
Affichage du nombre total de données du fichier source dans la liste des imports (Nouveauté 1.2.0)

Et l'ajout de la possibilité de télécharger en CSV les données sources d'un import directement depuis l'interface (possible depuis DBeaver ou autre actuellement).

Nouveau MCD du module :

geonature2db_demo - gn_imports

PnX-SI / gn_module_import