Chargement des données en plusieurs dataframe

[bouttier]

Ceci afin de réduire l’empreinte mémoire de l’import de gros fichier.

[codecov]

Codecov Report

All modified lines are covered by tests ✅

Files	Coverage Δ
...kend/gn_module_import/checks/dataframe/__init__.py	95.12% <100.00%> (+1.45%)	⬆️
backend/gn_module_import/conf_schema_toml.py	100.00% <100.00%> (ø)
backend/gn_module_import/tasks.py	92.38% <100.00%> (+1.36%)	⬆️
backend/gn_module_import/utils.py	95.00% <100.00%> (+0.58%)	⬆️

📢 Thoughts on this report? Let us know!.

[camillemonchicourt]

En lien avec les soucis de chargement de la RAM : PnX-SI/GeoNature#2717

Cette PR concerne l'amélioration de l'étape 3 du processus de traitement des données à importer :

• Étape 1 : upload du fichier, qui va être sauvegardé dans le champs binaire t_imports.source_file
• Étape 2 : lecture du champs binaire t_imports.source_file pour peupler la table t_imports_synthese (c’est de cette étape que parle Chargement des données en base en asynchrone #431 et qui nécessite le passage de GeoNature à SQLAlchemy 1.4)
• Étape 3 : chargement de la table t_imports_synthese dans une dataframe, et exécution d’une première partie de tests sur cette dataframe, avant de renvoyer les données de la dataframe dans la table t_imports_synthese (c’est cette étape qui est concernée par cette PR)
• Étape 4 : exécution des tests SQL directement sur la table t_imports_synthese

Le chargement en dataframe et l’exécution des tests dessus était déjà fait en asynchrone, on a donc pas de contrainte de temps majeur (pas de timeout possible). Par contre comme on charge toutes les données d’un coup, on a une grosse empreinte mémoire. C’est pour diminuer la consommation de RAM que c’est utile de procéder en plusieurs fois en chargeant uniquement une partie des données à chaque fois.

D'autres soucis de consommation de mémoire ont été améliorés dans #486, notamment lors de l'étape d'analyse des colonnes du fichier source.