Nous rencontrons un soucis lors de l’import de nos modules, lié à l’historique de nommage des attributs et objets métiers. Nous utilisons Git pour versionner nos modules. Nos modules sont stocké en JSON, en version éclatée /
Exemple
Voici un extrait de deux fichiers posant problème :
./configuration/ObjectInternal/Events :
Lorsque j’importe cette conf, que ce soit via la liaison avec mon repo git ou via un import de mon module au format zip, j’obtiens bien une historisation du nom de mes attributs et objets métiers, mais cette historique est erroné.
Pour l’Objet métier Events, l’historique que j’obtiens contient le nouveau nom d’objet métier Events et non l’ancien PendingIssues
De la même façon, l’historique de nommage de mon attribut eventsName n’est pas pendingIssuesName mais bien eventsName.
Enfin, lors de l’export de ma conf, que ce soit via un commit git sur le repo (avec push) ou via un export de ma conf en format zip éclaté, je perds la totalité de l’historique de nommage sur mes attributs et objets métiers concernés.
Nous sommes actuellement en V6.1.15. Le point a déjà été identifié par notre équipe en V6.0.XX.
Ca me semble un fonctionnement normal ou alors je ne suis pas sûr d’avoir compris votre problème.
La oldvalue dans le le module exporté provient des onglets Historique DB de renommage des Objets et Attributs. Vous pouvez les supprimer une fois que le module a été livré partout.
La oldvalue sert à retrouver l’objet/le champ préexistant dans la base où le module est importé (puisque la value est inconnue en cas de renommage, cela évite de recréer un objet/champ, voir une table ou autre colonne si les noms physiques ont été aussi modifiés).
Les objets Historique DB ne sont pas des objets de configuration (i.e. ils n’ont pas de module), ils servent juste à générer les “oldvalue” dans le module.
Il est donc normal de ne trouver dans l’historique cible que les nouvelles valeurs de l’objet/attribut modifiées, comme n’importe quel objet importé avec historique.
Nous avons effectivement besoin de cette oldvalue le temps que les différentes sous-versions soient déployées sur nos différents environnements. Notre soucis est que ces oldvalue, qui proviennent effectivement de l’historique DB, ne sont pas correctement importées lorsque nous importons la conf de notre version en cours de développement.
Pour exemple :
Si notre prod est en version 2.1 et que notre recette est en version 2.2.1 avec des historiques de nommage (oldvalue), les différents imports et exports de la version 2.2.1 sur nos environnements de développement pour préparer la version 2.2.2 entrainent une perte de ces historiques de nommage.
En réalisant les montées de version successives sur notre recette, nous perdons donc ces historiques qu’il nous faudrait pourtant conserver jusqu’à installation de la version 2.2.x en prod.
J’essaie de reformuler le comportement identifié lors de nos imports et exports de la version 2.2.1 de notre exemple :
Livraison de la version 2.2.1 depuis un environnement de dev vers un environnement de recette avec historique de nommage sur un objet Events (oldvalue = PendingIssues) et sur un attribut eventsName (oldvalue = pendingIssuesName).
Import sur un environnement de développement de la version 2.2.1 → Les historiques de nommage nous montrent que :
L’objet métier Events : à 1 historique lié à un changement de nom. Ancien nom indiqué dans l’historique : Events
L’attribut eventsName : à 1 historique lié à un changement de nom. Ancien nom indiqué dans l’historique : EventsName
Export depuis mon environnement de développement vers le git (en JSON Eclaté) des développement réalisée, constituant la version 2.2.2. → Les historiques de nommage (oldvalue) de mon objet métier et de mon attribut ne sont plus présent dans les fichiers de conf respectifs :
Pour l’objet métier Events : ./configuration/Ojectinternal/Events
Pour l’attribut eventsName : ./configuration/Field/eventsName
Supposée mise en production de la version 2.2.x
Les oldvalue n’étant plus présentent dans notre conf, le renommage ne s’effectue pas correctement et l’installation de la version entraîne la création d’un nouvel objet métier Events sans remplacer l’objet métier PendingIssues
En effet, les olvalue sont prévues pour être exportées depuis les tables historiques mais pas importées, et dans votre contexte d’usage où un 2eme environnement de dev vide importe le module, il perd les historiques de renommage de l’environnement “master”. Il faudrait que ce soit toujours le master qui merge et commit le module final à livrer en recette/prod, mais dans votre cas de gestion de versions, cela ne semble pas possible.
Pour corriger/contourner à court terme, vous allez être obligés de reporter les historiques à la main c.a.d modifier ou exporter/importer en dehors du module, suivant la quantité il faudra :
en tant que designer, modifier les droits CRUD sur ces objets FieldHistoric et/ou ObjectInternalHistoric pour pouvoir faire des modif/exports/import XML
Voir les ajouter au menu principal pour les exporter en masse depuis votre master, et faire l’import XML sur vos autres environnements de dev.
Idem si vous faites des renommages ailleurs, il faudra gérer le merge des historiques concurrents après import.
De notre côté, on va voir pour “importer” les oldvalue depuis le module vers les tables historiques, ce qui n’est pas sans poser problème en terme de date, par exemple si d’autres renommages ont eu lieu par la suite sur l’autre version, car on n’a plus la date du changement ou le numéro de version dans la table historique. On devra alors plutôt envisager de remettre ces historiques dans le module pour garder l’ensemble des données partout (avoir un row_module_id dans les tables ce qui est plus lourd en terme d’évol).
