Bug #57426
les slugs des sources de données automatiques depuis Chrono ne sont pas "déterministes"
0%
Description
Depuis deux Chrono ayant les mêmes agendas avec les mêmes slugs, on arrive à deux wcs avec des sources de données ayant des slug différents.
Historique
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
C'est déterministe, c'est juste que ça a changé entre le moment où les agenda ont été crée et maintenant. Avant on utilisait la génération automatique de slug, maintenant il est forcé depuis le slug dans chrono.
https://git.entrouvert.org/wcs.git/commit/?h=f48199fa92549dddd89cdc9cbcef19aa97370032Mis à jour par Thomas Noël il y a plus de 2 ans
- Statut changé de Nouveau à Rejeté
Benjamin Dauvergne a écrit :
C'est déterministe, c'est juste que ça a changé entre le moment où les agenda ont été crée et maintenant. Avant on utilisait la génération automatique de slug, maintenant il est forcé depuis le slug dans chrono.
Effectivement.. et en plus c'est moi qui avait parlé de ça (#54889) ! Notons que dans le cas qui m'intéresse sur le wcs de départ j'ai aussi des slug "xxx_1" suite à une résolution de conflit à un moment donné, ça ne sera pas repris non plus lors de la re-création sur le nouveau site (car il n'y aura pas de conflit).
Bref tout cela n'est pas très idéal... mais ça va être difficile de faire mieux, donc je rejette ce ticket qui est né d'un wcs de départ pré-54889 (et donc, en fait, impossible à migrer). Il faudrait imaginer que l'export des data_source exporte quand même les data_source Chrono et que l'import sache les gérer, c'est une autre affaire, loin de l'énoncé de ce ticket, que je rejette donc.
Mis à jour par Benjamin Dauvergne il y a plus de 2 ans
Thomas Noël (congés → 11 octobre) a écrit :
J'ai une règle perso à ce sujet qui n'a pas eu un gros succès pour l'instant avec toute le monde il me semble et que je ne n'ai pas appliqué uniformément, mais pour tout ce qui est "exportable/exporté" que ce soit via des web-service ou autre :Bref tout cela n'est pas très idéal... mais ça va être difficile de faire mieux, donc je rejette ce ticket qui est né d'un wcs de départ pré-54889 (et donc, en fait, impossible à migrer). Il faudrait imaginer que l'export des data_source exporte quand même les data_source Chrono et que l'import sache les gérer, c'est une autre affaire, loin de l'énoncé de ce ticket, que je rejette donc.
- en interne : utiliser un identifiant technique immuable local ou global comme référence partout (primary key ou uuid), jamais autre chose,
- à l'export : quand on exporte une référence ou l'objet lui même, exporter uuid, jamais l'identifiant technique local, et une ou des clés naturelles (slug, name, url, whatever... plus il y en a mieux c'est) mais les clés naturelles sont localement toujours modifiables sans impact, elles servent juste d'indice pour la réconciliation, si on a du mal avec la réconciliation on peut toujours introduire de nouvelles clés naturelles pour arranger les choses.