Migration des versions de taxref sans la table bib_noms

[amandine-sahl]

La table bib_noms permettait de détecter les changements de grappes de cd_nom présents dans cette table. En l'absence de cette table, il n'est plus possible de réaliser cette opération sauf en considérant l'ensemble des changements de taxref.

2 solutions sont possibles :

• 1 : Considérer les changements en se basant sur la table taxref ce qui augmenterait considérablement le nombre de cas possible et la complexité de l'opération
• 2 : Ne considérer que les changements de cd_ref (en se basant sur les tables attributs et médias)

La solution 2 réduit le nombre de cas possible à 3:

• Aucun changement : cd_ref1 -> cd_ref1
• Changement de cd_ref : cd_ref1 -> cd_ref2
• Merge : cd_ref1 + cd_ref2 -> cd_ref3
• Split : impossible à détecter

La question est : est-ce un soucis de ne plus détecter les cas de split et de partir sur la solution 2.

[camillemonchicourt]

• Cela continuerait quand même à vérifier et appliquer les changements dans les données de GeoNature ?
• Comment seront gérés les cas de split ? Il faudra les détecter ou appliquer manuellement ?

[amandine-sahl]

Cela continuerait quand même à vérifier et appliquer les changements dans les données de GeoNature ?

Les changements dans les données de GeoNature ne sont pas réalisées par TaxHub. Donc aucun changement de ce coté là. Ce qui était fait c'était la mise en évidence des cd_noms présents dans les données de la base (détecté via les contraintes d'intégrité référentielle) qui ne sont plus présent dans la nouvelle version de taxref

Comment seront gérés les cas de split ? Il faudra les détecter ou appliquer manuellement ?

En analysant les modifications en se plaçant au niveau des cd_ref, ce changement n'est plus vraiment identifiable, ce qui change se sont les "grappes" de cd_nom associé à un cd_ref. Le cd_ref lui est juste "déclassé" et remplacé par un autre.

[camillemonchicourt]

Fait dans la version 2.0.0