Migration TaxRef

[geobrun]

Bonjour,

Je suis en train de migrer notre référentiel TaxRef 11 vers TaxRef 13. Lors de l'exécution du script 1.1_taxref_changes_detections.sql, la table tmp_taxref_changes.comp_grap ne peut pas être créée ce qui visiblement bloque la suite de la migration. Après quelques recherches, cela vient visiblement de la ligne 13 à cet endroit : sort(array_agg(cd_nom)). L'exécution de ce code me renvoie l'erreur suivante : array must not contain nulls.

Visiblement, la fonction sort() doit ordonner les "cd_nom" dans les tableaux d’agrégats. Du coup, j'ai remplacé sort(array_agg(cd_nom)) par array_agg(cd_nom ORDER BY cd_nom) ce qui a l'air de produire le résultats attendu (tri des "cd_nom" dans les tableaux d'agrégats).

Qu'en pensez-vous ?

[amandine-sahl]

Effectivement cela doit donner le même résultat.
Par contre je m'étonne qu'il y ai des cd_nom null. Savez vous qu'elle est la colonne concernée?

[geobrun]

C'est bien ce qui est le plus troublant : il n'y a aucun cd_nom null dans la table !

[camillemonchicourt]

OK à voir si il y a une améliorations à faire dans le script de migration ?

[geobrun]

Autant pour moi, j'ai bien environ 850 cd_nom qui sont null dans ma table, j'avais du mal vérifier la première fois...

Est-ce que cela peut provenir d'une ancienne migration de Taxref 11 vers Taxref 13 que j'ai tenté de réaliser il y a quelques mois sans succès ? Il ne me semblait pas avoir exécuté le script apply_changes.sh pourtant.

Il y a un moyen de remettre Taxref 11 dans la table bib_noms ? Cela doit bien se trouver dans l'un des scripts SQL lors de l'installation de Taxhub ?

[amandine-sahl]

Je ne sais qu'elle est l'origine des cd_nom null. Il n'y a aucune requête de mise à jour de cd_nom dans les scripts de migration à ma connaissance.

Qu'entends tu par remettre Taxref 11 dans la table bib_noms?

[geobrun]

Effectivement, après avoir épluché la documentation, ça n'a pas vraiment de sens de vouloir remettre Taxref dans la table bib_noms, désolé.

Finalement, le plus simple, c'est que je récupère un table bib_noms non corrompue dans une de mes anciennes sauvegardes et que je la charge dans la table actuelle. D'après ce que j'ai pu voir, j'ai une table bib_noms datant de septembre dernier où il n'y a pas de valeurs nulles et où les id_nom ont l'air d'avoir les mêmes cd_noms que dans ma table actuelle (sauf pour les nuls bien sûr). Mais je vais quand même vérifier qu'ils sont bien tous identiques avant de charger l'ancienne table. Qu'en penses-tu ?

[amandine-sahl]

C'est une bonne chose de repartir sur des données propres

[amandine-sahl]

Attention si tu es avec un postgresql < 12 il y a une version nouvelle version corrective pour le passage de taxref v11 à v13
https://github.com/PnX-SI/TaxHub/releases/tag/1.8.1

[geobrun]

Ok, merci, j'ai une version 10.17 donc je suis concerné. Je vais restaurer la table "bib_noms", passer en version 1.8.1 et ensuite effectuer la migration.

Je viens de remonter mes différentes sauvegardes : a priori, ma table "bib_noms" était encore non corrompue début juin. Je suis en train de regarder l'avant-dernière sauvegarde que j'ai faite il y a une semaine pour comprendre d'où le problème a pu venir.

La seule chose que j'ai faite de travers a priori, c'est d'avoir tenté une première fois la migration de Taxref 11 vers Taxref 14 sans passer par la 13 (avec un Taxhub 1.8.0). Je n'ai vu qu'après sur Github qu'il fallait passer d'abord par la 13 pour aller de la 11 vers la 14.

[geobrun]

Je viens de me remettre sur le problème. J'ai restauré la table bib_noms à une version antérieure qui ne contenait pas de valeurs nulles dans la colonne cd_nom. J'ai ensuite déployé Taxhub 1.8.1 et lancé le script ./import_taxref_v13_data.sh.

Même comportement que la semaine dernière : j'ai de nouveau des enregistrements qui sont supprimés dans la table bib_noms et environ 450 cd_nom qui deviennent nuls (et une erreur pendant l'exécution du script). La semaine dernière, j'avais passé en revue toute mes sauvegardes de la table bib_noms : la dernière que j'avais effectué juste avant de lancer le script ./import_taxref_v13_data.sh était encore juste.

Voici le log que je reçois (je n'ai mis que le début). Est-ce cela dit quelque chose à quelqu'un ?

NOTICE:  extension "intarray" already exists, skipping
CREATE EXTENSION
DROP TABLE
SELECT 549099
DROP TABLE
CREATE TABLE
DROP TABLE
CREATE TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
ALTER TABLE
COPY 595373
COPY 8874
DELETE 117394
COPY 117394
DO
psql:scripts/0.2.1_correction_cd_nom_disparus.sql:9: ERROR:  column "commentaire_disparition" of relation "bib_noms" already exists
psql:scripts/0.2.1_correction_cd_nom_disparus.sql:10: ERROR:  column "deleted" of relation "bib_noms" already exists
UPDATE 547519
psql:scripts/0.2.1_correction_cd_nom_disparus.sql:15: ERROR:  constraint "fk_bib_nom_taxref" of relation "bib_noms" does not exist
UPDATE 732
INSERT 0 455
UPDATE 0
COPY 732
psql:scripts/1.1_taxref_changes_detections.sql:7: NOTICE:  schema "tmp_taxref_changes" already exists, skipping
CREATE SCHEMA
psql:scripts/1.1_taxref_changes_detections.sql:9: NOTICE:  table "comp_grap" does not exist, skipping
DROP TABLE
psql:scripts/1.1_taxref_changes_detections.sql:43: ERROR:  array must not contain nulls

Merci !

[geobrun]

En fouinant un peu plus, visiblement, ce serait ces lignes dans le script 0.2.1_correction_cd_nom_disparus.sql qui introduiraient les 455 enregistrements avec des cd_nom nuls.

-- Ajout du cd_nom de remplacement quand il n'existait pas dans bib_noms
INSERT INTO taxonomie.bib_noms(cd_nom, cd_ref, nom_francais)
SELECT cd_nom_remplacement, n.cd_ref, n.nom_francais
FROM taxonomie.bib_noms n
JOIN taxonomie.cdnom_disparu d ON n.cd_nom = d.cd_nom
ON CONFLICT DO NOTHING;
------------- AUTRES CAS à GERER

[geobrun]

Quelques informations complémentaires. En repassant le code du script 0.2.1_correction_cd_nom_disparus.sql, voici ce qui se passe lors des différents bouts de code.

Premier bout de code

--- CAS 1 - cd_nom de remplacement à utiliser.
UPDATE taxonomie.bib_noms n  SET deleted = true , commentaire_disparition = raison_suppression || ' nouveau cd_nom :' || cd_nom_remplacement
FROM (
	SELECT d.*
	FROM taxonomie.bib_noms n
	JOIN taxonomie.cdnom_disparu d
	ON n.cd_nom = d.cd_nom
	--AND cd_nom_remplacement IN (SELECT DISTINCT cd_nom FROM taxonomie.bib_noms)
)a
WHERE n.cd_nom = a.cd_nom;

Les 732 enregistrements de la table bib_noms dont le cd_nom a disparu dans Taxref 13 sont mis à jour. Leur champ deleted passe à true.

Second bout de code

INSERT INTO taxonomie.bib_noms(cd_nom, cd_ref, nom_francais)
SELECT cd_nom_remplacement, n.cd_ref, n.nom_francais
FROM taxonomie.bib_noms n
JOIN taxonomie.cdnom_disparu d ON n.cd_nom = d.cd_nom
ON CONFLICT DO NOTHING;

Parmi ces 732 enregistrements, 455 n'ont pas de cd_nom_remplacement dans la table cdnom_disparu. De ce fait, ce bout de code ajoute 455 nouveaux enregistrements à la table bib_noms avec des cd_nom nuls.

Dernier bout de code

UPDATE taxonomie.bib_noms n  SET deleted = true , commentaire_disparition = raison_suppression
FROM (
	SELECT d.*
	FROM taxonomie.bib_noms n
	JOIN taxonomie.cdnom_disparu d
	ON n.cd_nom = d.cd_nom
)a
WHERE n.cd_nom = a.cd_nom AND not deleted = true;

Si je comprends bien l'utilité de ce dernier bout, ces lignes devraient faire passer le champ deleted des 455 lignes insérées juste avant en true. Cela devrait permettre de ne pas traiter les cd_nom nuls lors de la création de la table tmp_taxref_changes.comp_grap (cf. script 1.1_taxref_changes_detections.sql). Ai-je raison ? Or, la mise à jour ne se produit pas (0 updates). En effet, pour que la mise à jour se fasse, il faudrait que ces 455 enregistrements aient un cd_nom non nul pour effectuer une jointure, ce qui n'est pas le cas.

Est-ce que ces explications éclaircissent mon problème ? Si mon raisonnement est juste, je pourrai dans ce cas peut-être supprimer arbitrairement les 455 enregistrements en question ou passer leur champ deleted en true. Le risque étant que cela perturbe ensuite les scripts de mise à jour suivants...

Sinon, étant donné que nous n'avons que 400 espèces identifiées dans notre synthèse, et qu'après vérification, leur cd_nom n'a pas changé entre Taxref 11 et 13, il est peut-être plus simple dans mon cas d'écraser Taxref 11 par Taxref 13 sans passer par l'étape "détection des changements de cd_nom dans la synthèse" ?

[amandine-sahl]

Effectivement le script ne prend en compte que les cas des cd_nom ayant un cd_nom de remplacement. C'est une limitation actuelle du au fait que nous n'avons jamais réellement eu de cd_nom sans cd_nom de remplacement. Il faudrait que l'on y remédie.

Par contre je suis étonnée de la quantité de cd_nom présent dans bib_nom qui sont supprimés. Vous avez ajouté tout le taxref dans bib_nom? Si c'est le cas sachez que la version 2.7 de GeoNature ajoute la fonctionnalité de ne pas avoir de liste prédéfinie pour un jdd et d'éviter ce contournement (de mettre tout taxref dans bib_noms).

Les scripts de migrations sont particulièrement utiles dans le cas ou vous avez des médias ou des attributs dans taxref. Si vous n'en avez pas ou peu je vous conseillerais de nettoyer votre table bib_noms de façon à ce qu'elle ne contienne que des données reliées à des attributs, liste ou médias de façon à limiter le nombre de changement. Et si vous ne souhaitez pas limiter la saisie des taxons dans occtax d'utiliser la fonctionnalité aucune liste de GeoNature (PnX-SI/GeoNature#1315).

[camillemonchicourt]

OK @amandine-sahl, merci pour ce retour.
OK donc cela permet d'identifier une amélioration à apporter au script de migration Taxref.
Et en effet dans GN 2.7.0, on peut désormais ne pas définir de liste de taxons pour un JDD ou pour tout Occtax, et taper directement dans tout Taxref.

[geobrun]

Ok, merci pour le retour !

Quand je suis arrivé ici, j'ai repris une instance de GeoNature déjà installée et je n'avais jamais eu l'occasion de jeter un oeil à la table bib_noms. Je pense que je n'ai pas encore bien saisi son utilité, si ce n'est qu'elle fait le lien entre Taxref et les tables gérant les listes, les attributs et les médias. Du coup, je peux vous dire qu'il y a bien tout Taxref 11 dans cette table de mon côté, donc environ 547 000 enregistrements !

Dans ce cas, je vais nettoyer cette table. Est-ce que je laisse le ticket ouvert par rapport au problème qui resterait à gérer (les cd_nom_remplacement vides) ou est-ce que je le ferme car c'est un problème marginal ?

[camillemonchicourt]

bib_noms sert à faire des listes de taxons, notamment pour limiter la saisie Occtax aux taxons connus de ton territoire.
Idem pour les médias et les atrributs, ne les ajouter que sur des taxons connus de ton territoire.
A la base il servait aussi à renseigner des noms français quand ils n'existaient pas dans Taxref, mais c'est de moins en moins le cas.

On réfléchit à supprimer bib_noms mais garder la possibilité de créer des listes de taxons pour Occtax ou pour des protocoles particuliers.

[geobrun]

Ok, c'est bon, la migration vers Taxref 13, puis Taxref 14 s'est bien passé vendredi dernier ! Merci beaucoup pour votre aide ! :)

[amandine-sahl]

Du coup je peux fermer le ticket?

[geobrun]

Oui, pas de problème, je te le ferme même !

[camillemonchicourt]

Il y avait quand même cette remarque :

Effectivement le script ne prend en compte que les cas des cd_nom ayant un cd_nom de remplacement. C'est une limitation actuelle du au fait que nous n'avons jamais réellement eu de cd_nom sans cd_nom de remplacement. Il faudrait que l'on y remédie.

A mettre dans un autre ticket @amandine-sahl ?