je rencontre un problème majeur et bloquant sur notre projet LADOM actuel. Nous sommes entrain de préparer la migration de notre workflow sur notre repository Gitlab afin d’historiser nos dev et d’utiliser toute les fonctionnalités du Gitflow. Cependant une contrainte interne nous empêche de déposer des fichiers aux extensions .zip et d’utiliser la fonctionnalité LFS.
Sur notre projet nous utilisons les fonctionnalités des Jeux de données de notre module. Ce jeux de données est primordial au bon fonctionnement de notre application car il intègre toutes les données de l’application.
Notre contrainte interne ne nous permet donc pas d’utiliser un .zip. Mais nous devons déposer le fichier contenant toutes nos données applicatives pour historiser et avoir un suivi sur ces données.
Malheureusement je constate une grosse anomalie sur l’export du jeux de données. En effet il est possible d’exporter le jeux de données vers un autre format que le xml comme en JSON ou XML.
Cependant lorsque j’utilise l’export, le fichier généré ne contient plus du tout les données d’origine et réalise un encodage en base 64 qui n’est plus lisible (j’ai tenté plusieurs formats d’encodage tous en echec). La taille du fichier est divisé par 10 ce qui n’est pas normal.
Et lors de l’import du nouveau fichier exporté, l’import se fait bel et bien (très rapide anormal en comparaison au fichier d’origine) mais aucune données n’est chargées.
Merci de corriger rapidement ce bug ou bien de nous trouver une solution au plus vite.
Cordialement.
Yan MICHIELS
Ingénieur Concepteur chez Orange Business Services
Steps to reproduce
1.Exporter un jeux de données actuel et fonctionnel
2.Exporter dans un format json par exemple
3. Constater que la taille de fichier du nouveau fichier exporté n’est pas la même que le fichier d’origine
4. Constater que dans le nouveau fichier, un encodage en base 64 est visible. Lors de son décodage aucune donnée n’est interprétable
5. Constater lors de l’import du nouveau fichier qu’aucunes données est chargées.
Pour commencer pouvez vous nous indiquer sur quelle version de Simplicité vous travaillez.
L’export des données est une fonctionnalité qui n’a pas été prévue, à date, pour générer autre chose qu’un fichier au format ZIP (i.e. un XML qui référence des fichiers dans une arborescence).
Le ZIP ainsi constitué s’exporte nominalement avec le module auquel il est rattaché dans le répertoire data du repo Git du module (et des formats d’exports de module ZIP ou tar.gz qui ont le même layout que le repo Git).
Je ne suis pas sûr de bien comprendre que vous faites mais si vous exportez manuellement l’objet DataSet en XML ou JSON, le fichier ZIP contenant les données va se retrouver encodé en base 64 dans le XML ou le JSON d’export de cet objet, et en fonction du volume de ce fichier on touche peut être des limites techniques des parsers en charge de decoder les contenus base 64. Si c’est ça que vous faites ça ne me semble pas une bonne procédure, en tout cas ça n’a pas été conçu pour être fait de cette manière.
Mis à jour dans mon message précédent donc version 5.2.34.
Je ne comprend pas alors pourquoi il y’a une possibilité d’export si celle-ci ne fonctionne pas du tout.
L’option export figure bel et bien et j’ai la possibilité de cocher toutes les données dans le format souhaité comme mentionné dans ma capture d’écran sur l’export.
Si cela ne fonctionne pas alors quelle est utilité de permettre quelque chose qui ne marche pas, je ne comprend vraiment pas…
Ma demande est simple c’est de pouvoir stocker le fichier qui d’origine est en .zip contenant le xml de toutes les données de notre application dans un format autre que le .zip car nous avons des contraintes interne qui nous empêche de stocker du .zip. Je ne souhaite pas d’encodage mais simplement les données en clair et qu’elles soient dans un format JSON ou XML idéalement.
Quelle solution vous me proposez pour permettre ceci ?
Indépendamment du point sur les datasets, la révision 5.2.34 que vous utilisez date de mars 2023, la révision actuelle est la 5.2.52 entre ces 2 révisons il y a eu plus de 320 commits y compris des correctifs de sécurité importants. Vous devez vous mettre à jour plus régulièrement sur les révisions de maintenance.
En outre la version mineure 5.2 est arrivée en fin de maintenance
à fin septembre 2023, vous devez donc désormais envisager de passer en 5.3 qui sera la dernière version mineure de la version majeure 5 qui, elle, sera en maintenance long terme (3 ans à dater de la release de la version majeure 6 prévue en début 2024)
En toute rigueur on aurait dû effectivement inhiber la possibilité d’exporter au niveau de l’objet DataSet car c’est prévu pour se gérer via le module mais par défaut dans Simplicité tout objet est exportable…
Cela dit, je viens de tester avec un dataset de taille raisonnable, et ça fonctionne:
je constitue le dataset via l’action “Export data” du module:
Bref, soit la procédure que vous appliquez est différente, soit il y a une limite technique dans la capacité à décoder un contenu base 64.
Mais, à nouveau, vous ne devriez de toute façon pas procéder de cette manière (= en exportant l’objet DataSet) mais uniquement télécharger le ZIP des données du dataset. Si vous avez une contrainte de stockage en configuration de ce fichier ZIP rien ne vous empêche de le dézipper après export et de le rezipper avant importer
