Simplification des dags source et ajout du contexte

[kolok]

Description succincte du problème résolu

Suppression de pas mal d'étape :

Les tâches de formatage de la données sont remplacées par la tâche compute_link_tables
Les tâches de récupération des mapping des objets d'adminitration sont supprimées car ces mappings ne sont utilisé que par compute_link_tables et donc on récupère ces mapping en entrée de cette tache uniquement
La tâche d'identification des acteurs à supprimer est supprimée et cette identification est faite dans la tâche db_data_prepare

RAF dans une prochaine itération :

• possibilité de supprimer la tâche propose_acteur_changes -> transférer les actions de cette tache à la tâche de normalisation

Type de changement :

• Bug fix
• Nouvelle fonctionnalité
• Mise à jour de données / DAG
• Les changements nécessitent une mise à jour de documentation
• Refactoring de code (explication à retrouver dans la description)

Auto-review

Les trucs à faire avant de demander une review :

• J'ai bien relu mon code
• La CI passe bien
• En cas d'ajout de variable d'environnement, j'ai bien mis à jour le .env.template
• J'ai ajouté des tests qui couvrent le nouveau code

Comment tester

En local / staging :

• …

[maxcorbeau]

Peux-tu stp expliquer les changements dans les grandes lignes?

[maxcorbeau]

@kolok : j'ai relu l'explication d'ensemble (pas encore le code). Ma compréhension:

• tâches de récupération des mapping: on déplace là ou c'est utilisé (compute_link_tables)
• tâche d'identification des acteurs à supprimer: on déplace là ou c'est utilisé (db_data_prepare)

En revanche c'est pas clair pour moi:

Les tâches de formatage de la données sont remplacées par la tâche compute_link_tables

• Pourquoi? Qu'y avait-il de non-désiré, sous-optimal etc... avec la situation actuelle?

[kolok]

En revanche c'est pas clair pour moi:

Les tâches de formatage de la données sont remplacées par la tâche compute_link_tables

* Pourquoi? Qu'y avait-il de non-désiré, sous-optimal etc... avec la situation actuelle?

Parce que les tâches créait des DFs pour chaque table de lien qui étaient ensuite mergé à la DF acteur alors qu'il suffisait de résoudre le mapping d'ID directement dans la df_acteur
Ca nous permet aussi de virer la gestion des id des proposition de service qui était utilisé uniquement pour la gestion de ces DFs par table de lien

[fabienheureux]

looks good, 2-3 commentaires malgré tout, absolument pas bloquants

[maxcorbeau]

Dans l'ensemble cela semble une amélioration significative si pour la même fonctionalité on a réussi à simplifier 🥳 aussi drastiquement:

• lignes de codes = +711 −1,361 = -650 lignes
• fonctions dans aurflow_logic = +1 - 7 = -6 fonctions

Donc félicitations. Je dirais vigileance sur le nommage et commentaires pour conserver le code compréhensible (ex: compute_link_tables)