Migration TaxRef v17 problème conflits

[jpm-cbna]

Lors de la migration de TaxRef v17, nous obtenons 48 lignes avec pour valeur dans le champ action Conflicts with attributes : .... Or, pour 30 d'entres elles, les conflits en question n'en sont pas mais correspondent plutôt au cas 4 "split and merge" bien que le script détecte ces lignes en tant que cas n°3 "merge".
La différence par rapport au schéma c'est que le cd_ref2 continue d'exister dans la nouvelle version de TaxRef, il ne disparaît pas. C'est seulement un cd_nom (ex. cd_nom4) correspondant à un synonyme du nom retenu (cd_ref2) qui est transféré vers un cd_ref déjà existant (cd_ref1).

Schéma représentant le cas en question

Dans ce schéma, il faut considérer que "cd_nom1 = cd_ref1" et que "cd_nom5 = cd_ref5".
Dans tous les cas en question, nous avons des attributs associés aux cd_ref1 et au cd_ref5.
Dans ce cas là, il ne devrait pas y avoir de conflits liés aux attributs et/ou médias et le cd_nom4 devrait simplement changer de cd_ref.

Exemple concret

Et une image contenant les lignes de la table tmp_taxref_changes.comp_grap correspondant à un exemple du problème:

Dans cet exemple, nous avons 2 cd_ref 80988 (Ajuga pyramidalis) et 80990 (Ajuga reptans) qui sont tous les deux existants dans TaxRef v16 et v17 (pas de changement de cd_ref entre les deux versions). Le cd_ref 80990 a seulement un cd_nom (80985) qui est transféré dans la grappe du cd_ref 80988.

Le problème c'est que la colonne "action" contient des "Conflicts with attributes : " qui ne devraient pas exister puisque les cd_ref ne changent pas.

Proposition de solution

Il faudrait juste avant la détection des "Conlicts with attributes : ..." repérer les cas en question est définir l'action à Do not change attributes and media.

Il me semble également qu'il faudrait ignorer les cas ou i_cd_ref = f_cd_ref lors de la détection des conflits en ajoutant une clause i_cd_ref != f_cd_ref au WHERE.

Enfin, bien que les modifications ci-dessus semblent suffire, il faudrait peut être également ajouter une clause AND action IS NULL dans le WHERE de la requête détection les conflits.

[jpm-cbna]

Finalement, je me rends compte que la correction pourrait être plus simple.
Il suffit de corriger la requête de détection des conflits dans le fichier "1.2_taxref_changes_detections_cas_actions.sql" mais aussi les requêtes de mises à jour des tables "cor_taxon_attributs" "t_medias" dans le fichier "3.2_alter_taxref_data.sql".

Initialement, le script génère 48 conflits dont certains qui n'en sont pas vraiment :

Après correction des requêtes j'obtiens 20 conflits réel nécessitant bien une intervention manuelle en base:

Pour corriger les problèmes, je me suis rendu compte qu'il fallait ignorer les lignes ou le "i_cd_ref" n'était pas présent dans la liste "f_cd_nom_list" car cela indique une simple réattribution d'un nom de synonyme. Il n'y a pas de réel changement taxonomique. La table comp_grap ne fait pas apparaître explicitement le cd_nom du synonyme mais il est bien présent dans le champ "i_cd_nom_list" du "i_cd_ref".

Si on prend les 2 lignes où "f_cd_ref" vaut "80988" dans le tableau avant correction, on voit bien que le "i_cd_ref" 80990 n'est pas présent dans "f_cd_nom_list" ([80985, 80988]). C'est un synonyme du taxon 80990 qui a été attribué au taxon 80988. D'ailleurs, ces 2 cd_ref sont toujours valides et existant dans TaxRef v17. C'est le synonyme 80985 présent dans le champ "i_cd_nom_list" du "i_cd_ref" 80990 qui a été réattribué au "f_cd_ref" 80988.
La ligne 197 dans la requête corrige ce problème.

Il est également très important de ne pas modifier les cd_ref des tables "cor_taxon_attributs" "t_medias" pour les lignes où le "i_cd_ref" n'est pas présent dans "f_cd_nom_list". Les ajouts suivant dans le fichier "3.2_alter_taxref_data.sql" corrigent le problème.

Par ailleurs, les DISTINCT présents dans la requête de détection des conflits sont un problème car il est possible d'avoir plusieurs fois les mêmes valeurs d'attributs associées à des taxons distincts. Rien ne l'interdit dans TaxHub.
Du coup, en supprimant les distincts les conflits en question apparaissent correctement.

[camillemonchicourt]

A priori réglé dans la version 2 de TaxHub où les scripts de migration de Taxref ont été revus, notamment avec la suppression de bib_noms.