TaxHub
TaxHub copied to clipboard
PnX-SI
Migration TaxRef v16 problèmes cd_nom 111955, 129323
Je suis entrain de réaliser une migration de TaxRef v15 ver v16.
Je me suis retrouvé bloqué par le cd_nom 111955 car son cd_nom de remplacement n'est pas présent dans TaxRef v15 mais seulement dans TaxRef v16. Dans le fichier "missing_cd_nom_into_database.csv", j'ai:
+----------------------+--------+----------------------------------+--------------+------------------------+---------------------+-----------------------+
| table_name | cd_nom | nom_complet | nb_occurence | plus_recente_diffusion | cd_nom_remplacement | cd_raison_suppression |
+----------------------+--------+----------------------------------+--------------+------------------------+---------------------+-----------------------+
| gn_synthese.synthese | 111955 | "Oxycoccus vulgaris Bong., 1832" | 1 | 9.0 | 1008910 | 1 |
+----------------------+--------+----------------------------------+--------------+------------------------+---------------------+-----------------------+
Dans mon fichier "pre_detection.sql", j'ai mis:
ALTER TABLE gn_synthese.synthese DROP CONSTRAINT IF EXISTS fk_synthese_cd_nom;
UPDATE gn_synthese.synthese SET cd_nom = 1008910 WHERE cd_nom = 111955 ;
Dans mon fichier "post_detection.sql", j'ai:
ALTER TABLE gn_synthese.synthese ADD CONSTRAINT fk_synthese_cd_nom
FOREIGN KEY (cd_nom) REFERENCES taxonomie.taxref(cd_nom)
ON UPDATE CASCADE ;
Je lance la commande:
flask taxref migrate-to-v16 apply-changes --script_predetection /home/<chemin-vers-sql>/pre_detection.sql --script_postdetection /home/<chemin-vers-sql>/post_detection.sql
Quand la foreign_key est remise en place via le script "post_detection.sql" cela m'affiche l'erreur:
DETAIL: La clé (cd_nom)=(1008910) n'est pas présente dans la table « taxref ».
[SQL: -- Mise à jour TaxRef v15 vers v16 pour le SINP AURA
-- Rétablir les contraintes de clés étrangères spécifiques à votre base
ALTER TABLE gn_synthese.synthese ADD CONSTRAINT fk_synthese_cd_nom
FOREIGN KEY (cd_nom) REFERENCES taxonomie.taxref(cd_nom)
ON UPDATE CASCADE ;
En regardant de plus près dans les fichiers de TaxRef v16, je me rends compte que le fichier CDNOM_DISPARUS.xls contient:
+--------+------------------------+---------------------+-----------------------+------------------------------------+
| CD_NOM | PLUS_RECENTE_DIFFUSION | CD_NOM_REMPLACEMENT | CD_RAISON_SUPPRESSION | RAISON_SUPPRESSION |
+--------+------------------------+---------------------+-----------------------+------------------------------------+
| 111955 | 9.0 | 1008910 | 1 | cd_nom de remplacement à utiliser. |
+--------+------------------------+---------------------+-----------------------+------------------------------------+
Alors que le fichier TAXREF_CHANGES.tsv contient:
+--------+------------------+-------------------+--------+-------------+--------------+-------------+
| CD_NOM | NUM_VERSION_INIT | NUM_VERSION_FINAL | CHAMP | VALEUR_INIT | VALEUR_FINAL | TYPE_CHANGE |
+--------+------------------+-------------------+--------+-------------+--------------+-------------+
| 111955 | 15.0 | 16.0 | CD_NOM | 111955 | | RETRAIT |
+--------+------------------+-------------------+--------+-------------+--------------+-------------+
Est ce que ces 2 entrées ont un sens ? J'ai l'impression qu'il y a une erreur dans un de ces 2 fichiers, non ?
J'ai également un problème avec le cd_nom 129323 qui apparaît dans le fichier "CDNOM_DISPARUS.xls" avec une valeur du champ CD_RAISON_SUPPRESSION a 1 mais aucune valeur dans le champ CD_NOM_REMPLACEMENT.
Ce n'est d'ailleurs pas le seul, nous trouvons cette liste de cd_nom dans ce cas là:
+--------+------------------------+---------------------+-----------------------+------------------------------------+
| CD_NOM | PLUS_RECENTE_DIFFUSION | CD_NOM_REMPLACEMENT | CD_RAISON_SUPPRESSION | RAISON_SUPPRESSION |
+--------+------------------------+---------------------+-----------------------+------------------------------------+
| 13746 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 16472 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 18663 | 6.0 | | 1 | cd_nom de remplacement à utiliser. |
| 40994 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 57161 | 7.0 | | 1 | cd_nom de remplacement à utiliser. |
| 60700 | 7.0 | | 1 | cd_nom de remplacement à utiliser. |
| 85133 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 101903 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 101939 | 3.0 | | 1 | cd_nom de remplacement à utiliser. |
| 104864 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 108909 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 114457 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 116454 | 6.0 | | 1 | cd_nom de remplacement à utiliser. |
| 129323 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 132893 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 135450 | 6.0 | | 1 | cd_nom de remplacement à utiliser. |
| 151472 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 159609 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 159631 | 7.0 | | 1 | cd_nom de remplacement à utiliser. |
| 160372 | 6.0 | | 1 | cd_nom de remplacement à utiliser. |
| 161147 | 5.0 | | 1 | cd_nom de remplacement à utiliser. |
| 161504 | 3.0 | | 1 | cd_nom de remplacement à utiliser. |
| 161901 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 162142 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 162201 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 162202 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 397303 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 412926 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 455216 | 6.0 | | 1 | cd_nom de remplacement à utiliser. |
| 455834 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 571265 | 5.0 | | 1 | cd_nom de remplacement à utiliser. |
| 611282 | 6.0 | | 1 | cd_nom de remplacement à utiliser. |
| 614951 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 615123 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 644989 | 5.0 | | 1 | cd_nom de remplacement à utiliser. |
| 686180 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 693978 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 697913 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 697914 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 704233 | 7.0 | | 1 | cd_nom de remplacement à utiliser. |
| 805135 | 14.0 | | 1 | cd_nom de remplacement à utiliser. |
| 16233 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 1907 | 7.0 | | 1 | cd_nom de remplacement à utiliser. |
| 560293 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 396384 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 622897 | 7.0 | | 1 | cd_nom de remplacement à utiliser. |
| 455724 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 653285 | 8.0 | | 1 | cd_nom de remplacement à utiliser. |
| 521653 | 5.0 | | 1 | cd_nom de remplacement à utiliser. |
| 92731 | 9.0 | | 1 | cd_nom de remplacement à utiliser. |
| 123261 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 154923 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 104871 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 87522 | 4.0 | | 1 | cd_nom de remplacement à utiliser. |
| 161082 | 3.0 | | 1 | cd_nom de remplacement à utiliser. |
+--------+------------------------+---------------------+-----------------------+------------------------------------+
En attendant, j'ai pu finaliser la migration en mettant à NULL le champ cd_nom dans la table synthese pour les cd_nom posant problème. Les requêtes présentes dans le fichier "pre_detection.sql" ressemblent à celle-ci:
UPDATE gn_synthese.synthese SET
cd_nom = NULL,
additional_data = jsonb_set(
additional_data,
'{taxrefUpdate}',
jsonb_build_object('version', 16, 'previousCdNom', 111955),
true
)
WHERE cd_nom = 111955 ;
Est ce que ces 2 entrées ont un sens ? J'ai l'impression qu'il y a une erreur dans un de ces 2 fichiers, non ?
En fait pas vraiment le fichier CDNOM_DISPARUS.xls indique la version où le cd_nom est apparu, l'autre (TAXREF_CHANGES.tsv) celle où il a disparu.
Sinon pour les cas de cd_nom de remplacement apparaissant en v16 (donc ne sont pas présent dans la version actuel de taxref) plutôt que de supprimer le cd_nom (ou les contraintes d'intégrité), une autre option est de l'ajouter dans la table taxref dans le script predection. Il sera mis à jour par la suite ce qui ne posera aucun soucis.
En fait pas vraiment le fichier
CDNOM_DISPARUS.xlsindique la version où le cd_nom est apparu, l'autre (TAXREF_CHANGES.tsv) celle où il a disparu.
OK, si je comprends bien. Ces infos indiquent seulement que le cd_nom 111955 n'existe plus et qu'il doit être remplacé par le cd_nom 1008910.
Du coup, je vais tester ce que tu proposes en rajoutant le nouveau cd_nom 1008910 temporairement dans la table taxref (en v15) le temps que la migration se fasse...
@amandine-sahl Par contre, qu'en est-il pour le cd_nom 129323 dont la valeur du champ CD_NOM_REMPLACEMENT est vide alors que la raison de la suppression est "cd_nom de remplacement à utiliser." dans le fichier "CDNOM_DISPARUS.xls" ?
Par contre, qu'en est-il pour le cd_nom 129323 dont la valeur du champ CD_NOM_REMPLACEMENT est vide alors que la raison de la suppression est "cd_nom de remplacement à utiliser." dans le fichier "CDNOM_DISPARUS.xls" ?
Désolée je ne sais pas quoi dire, demande au MNHN
Par contre, qu'en est-il pour le cd_nom 129323 dont la valeur du champ CD_NOM_REMPLACEMENT est vide alors que la raison de la suppression est "cd_nom de remplacement à utiliser." dans le fichier "CDNOM_DISPARUS.xls" ?
Désolée je ne sais pas quoi dire, demande au MNHN
Oui, c'est ce que l'on avait prévu de faire avec @camillemonchicourt en fonction de ta réponse. Merci !
Salut, En fait le cd_nom 129323 n'a pas disparu et est toujours diffusé, donc pas de pb. La vraie question est plutôt : comment se fait-il qu'il se retrouve dans le fichier CDNOM_DISPARUS.xls... vieilles requêtes dans lesquelles il faut que je me replonge... bye Olivier
