20241031 - Acteurs inactifs reparation lvao

[maxcorbeau]

Description succincte du problème résolu

Ticket

• QUOI: modifier 6264 acteurs LVAO _reparation_ en changeant statut = INACTIF
• POURQUOI: les entrées dans la base sont obsolètes (SIREN cessé ou SIRET fermé)
• COMMENT:
  • intégration avec la base SIRENE en local
  • export et revue manuelle avec Christian (tableur fichier /data/6264_acteurs_a_desactiver.csv non inclu dans le commit)
  • execution des requettes SQL pour modifier qfdmo_acteur

Quality assurance

• Export: filtre sur ACTIF, vérification du nombre, pas de doublon sur identifiant
• Requettes SQL: vérifier existance de l'acteur avec identifiant_unique, s'assurer que modifie_le dans la base est pas plus récent que l'export, et seulement après MAJ de l'entrée dans la base

[kolok]

Je pense qu'il y a un loup !

les acteurs (qfdm_acteur) sont surdéfinis par les révision d'acteur (qfdmo_revisionacteur) du coup, si tu désactives les acteurs sans désactiver leur révision, les acteurs vont quand même apparaitre après le calcul des acteurs affichés

Si il n'y a pas de révisions sur les acteurs concernés alors ma remarque peut-être ignoré dans le cadre de cette PR mais il faudra y penser lors de l'automatisation

Pour résoudre le problème il y a 2 manières de faire:

• soit tu mets à jour les acteurs et leur révision si elles existent
• soit tu crées les revisions des acteurs et tu mets à jour le statut des révisions

[maxcorbeau]

Je pense qu'il y a un loup !

Du coup si je comprends bien:

• qfdmp_acteur: on ne devrait jamais modifier cette table autre que par le biais des DAG d'import
• qfdmp_revisionacteur: si je viens créer un acteur (si manquant) et mettre le statut = INACTIF, ce dernier prendra précédence sur qfdmp_acteur quel que soit l'état de qfdmp_acteur

[kolok]

Je pense qu'il y a un loup !

Du coup si je comprends bien:

* `qfdmp_acteur`:  on ne devrait jamais modifier cette table autre que par le biais des DAG d'import

Oui, encore qu'ici on intervient sur des données histroriques qui ne seront plus jamais mise à jour par un DAG d'import donc ça se discute

* `qfdmp_revisionacteur`: si je viens créer un acteur (si manquant) et mettre le `statut = INACTIF`, ce dernier prendra précédence sur `qfdmp_acteur` quel que soit l'état de `qfdmp_acteur`

Oui exactement

[maxcorbeau]

Oui, encore qu'ici on intervient sur des données histroriques qui ne seront plus jamais mise à jour par un DAG d'import donc ça se discute

Si:

• le point 2 est vrai (qfdmp_revisionacteur > qfdmp_acteur)
• la règle est que qfdmp_acteur = import, qfdmp_revisionacteur = révision
• on décide de modifier qfdmp_revisionacteur parce qu'on fait de la révision

Quel est l'intérêt de créer une nouvelle exception en modifiant qfdmp_acteur? (quelle valeur ajoutée vs. encore une exception qu'il faudra documenter, gérer dans le code ad-hoc, et qui peut-être amènera de la confusion à l'avenir: ex: "pourquoi le qfdmp_acteur.modifie_le est récent alors qu'on n'a pas importé la source depuis ____ ?")

[kolok]

Oui, encore qu'ici on intervient sur des données histroriques qui ne seront plus jamais mise à jour par un DAG d'import donc ça se discute

Si:

* le point 2 est vrai (`qfdmp_revisionacteur` > `qfdmp_acteur`)

* la règle est que `qfdmp_acteur` = import, `qfdmp_revisionacteur` = révision

* on décide de modifier `qfdmp_revisionacteur` parce qu'on fait de la révision

Quel est l'intérêt de créer une nouvelle exception en modifiant qfdmp_acteur? (quelle valeur ajoutée vs. encore une exception qu'il faudra documenter, gérer dans le code ad-hoc, et qui peut-être amènera de la confusion à l'avenir: ex: "pourquoi le qfdmp_acteur.modifie_le est récent alors qu'on n'a pas importé la source depuis ____ ?")

Faisons la modification sur qfdmo_revisionacteur, tu as raison, ça fer une exception en moins

[kolok]

Review avec Max

[kolok]

Il faut eviter de commit ce type de résultat

Ici rien de PPI donc c'est OK mais une habiture à prendre.

J'ai fait un commit pour nettoyer les ouputs des cellules