-
Notifications
You must be signed in to change notification settings - Fork 31
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
Comments
Finalement, je me rends compte que la correction pourrait être plus simple. 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 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. 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 |
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) et80990
(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_ref80990
a seulement un cd_nom (80985
) qui est transféré dans la grappe du cd_ref80988
.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
auWHERE
.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.The text was updated successfully, but these errors were encountered: