Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Migration TaxRef v17 problème conflits #527

Open
jpm-cbna opened this issue Aug 7, 2024 · 1 comment
Open

Migration TaxRef v17 problème conflits #527

jpm-cbna opened this issue Aug 7, 2024 · 1 comment
Assignees
Labels

Comments

@jpm-cbna
Copy link
Contributor

jpm-cbna commented Aug 7, 2024

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

unnamed
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:
unnamed
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
Copy link
Contributor Author

jpm-cbna commented Aug 9, 2024

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 :
Screenshot_20240809_144850

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant