Bonjour,
nous sommes en phases de migration vers la 5.2.16 (nous sommes en 5.1.45). J’ai un problème avec les nouveautés git.
Lorsque je clone clone le repo sur mon PC (windows 10) j’ai les erreurs suivantes :
J’ai configuré le référentiel en indiquant localhost comme c’était en 5.1 comme valeur par défaut.
Merci de votre aide,
Thierry
Je vais laisser @Francois vous expliquer la logique arborescente des nouveaux exports JSON explosés et les nommages qui en decoulent.
Pour lever globalement la limite de longueur de paths niveau windows il faut visiblement aller bidouiller dans la base de registre (ex: https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/), je n’ai jamais fait ça et ne peut donc pas garantir que ça marche ou que ça ne posera pas des problèmes par ailleurs => à voir avec le support Windows.
Sinon ça se traite visiblement aussi au niveau Git (coté client), cf. 3 Ways to Fix Git Clone "Filename too long" Error in Windows [Fixed] | JavaProgramTo.com, là aussi je n’ai jamais eu à le faire donc je ne sais pas si ça marche ou s’il y a des contraintes => à tester et à voir avec le support Git
Enfin vous pouvez aussi limiter la taille de ses nommages, ex: renommer votre liste de valeur de LADLADDEMANDEURTYPEPIECEIDENTITE en LAD_DEM_TYP_PI ou dans le genre
Bonjour,
Effectivement ce nouveau type d’export en fichiers JSON éclatés respecte la hiérarchie des objets en nommant les répertoires à partir des clés fonctionnelles de objets. C’est tout l’intérêt par exemple d’avoir le paramétrage d’un objet dans un seul répertoire du nom de l’objet.
Il faut à priori autoriser les path longs sur le client GIT :
git config --system core.longpaths true
mais suivant votre client GIT ça peut ne pas fonctionner.
En attendant de trouver une solution sur Windows
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
Bonjour
Je refais monter le sujet…
Effectivement, sous Windows (dans mon cas un Windows 11 avec un file system NTFS) quand on a des chemins complets dont la taille est importante (à priori > 260 caractères) Windows ne gère pas correctement les fichiers :
Sur certaines opérations on a ce message:
Sur d’autres ça ne dit rien…
Sur Linux pas de souci avec les chemins à rallonge (testé avec le même export de module). @scampano j’imagine que sur Mac c’est OK aussi…
Bref ce format JSON éclaté 5.2+ et Windows ne font pas bon ménage à moins de se restreindre dans les nommages (dans mon cas j’ai atteint la limite en configurant un treeview avec de nombreux “étages”).
@Francois vois-tu une manière de pendre en compte cette limitation technique de Windows tout en conservant l’intérêt une arborescence “hiérarchique” qui est humainement plus lisible et aide au diff/merge hors Simplicité. J’avoue ne pas avoir trop d’idée magique sur ce point…
PS: pour mémoire voici une commande Linux pour trouver les fichiers dont le chemin est > à une certaine longueur (ici 255):
tar tvfz MonModule.tar.gz | awk '{ print $NF }' | awk '{ if (length > 255) printf "%-5s %s\n", length, $0 }' | sort
PS:
Visiblement à partir de Windows 10 il y a une méthode officielle (documentation Microsoft) peut lever - volontairement - cette limitation par défaut à 260 caractères via une valeur ad hoc dans la base de registre: Maximum Path Length Limitation - Win32 apps | Microsoft Learn
Je n’ai pas encore testé…
Ah bon Windows n’est pas fait pour comparer des modèles relationnels de taille variable ?
Oui il faut chercher une solution côté Microsoft si on peut débrider les postes développeurs.
Sinon pas le choix que de tronquer applicativement quelque part, mais ça aura un impact
Dans les 2 cas, ça posera un pb de bijection entre la clé fonctionnelle et le chemin physique d’un objet
Pour un diff, cela oblige à avoir à la racine une correspondance fichier/table des noms physiques = nom logique, lourd car dénormalise en cas dde mise à jour manuelle…
Bref le maillon le plus faible fera encore revenir en arrière le reste qui était plus lisible.
A défaut de solution simple, on ne fera plus d’arbre, on reviendra à un répertoire par type d’objet.
Et faudra pas dire que c’est pas pratique.
J’imagine aussi, si t’as un tgz à me transmettre je teste.
Pour la taille des nommages, ça ne me semble pas idéal de faire porter la responsabilité au designer qui a une courbe d’apprentissage déjà bien raide; ces bonnes pratiques doivent être policées par la plateforme, ce qui semble difficile sans limiter les cas récursifs comme les treeviews.
Je vois, techniquement, plusieurs pistes d’amélioration :
Le path d’export (et la lisibilité de l’arbre) pourrait être ~drastiquement~ réduit à de nombreux endroits avec un algo json<->xml un peu plus élaboré. Je mets un exemple, mais une lecture rapide permet de détecter des cas similaires un peu partout.
configuration/Module/OSI/FieldList/OSIEFFLUENTRESEAUPRIVE/FieldListCode/OSIEFFLUENTRESEAUPRIVE-EP/FieldListValue/OSIEFFLUENTRESEAUPRIVE-EP-ENU/OSIEFFLUENTRESEAUPRIVE-EP-ENU.json
config/Module/OSI/FieldList/OSIEFFLUENTRESEAUPRIVE/FieldListCode/EP/FieldListValue/ENU.json
PS: amha l’intérêt de cette évol niveau propreté et lisibilité de l’export dépasse la question de la taille du path.
SyntaxTool, systématisation de l’utilisation des trigrammes plutôt que des noms d’objet, nommages auto des NN, etc etc
config/Module/OSI/FieldList/OSIEFFLUENTRESEAUPRIVE/FieldListCode/EP/FieldListValue/ENU.json
config/Module/OSI/FieldList/OSIEFFRESEAUPRIVE/FieldListCode/EP/FieldListValue/ENU.json
no comment
Ceci étant dit, ça ne résoud pas le problème de fond, qui est qu’on ne pourra jamais contrôler les cas récursifs comme le treeView, ce qui amène à une autre solution, qui a l’avantage d’être utilisable sans évol du socle la recommendation sur un process compatible avec un mode JSON ou XML non éclaté:
PS: J’ai à nouveau cherché les outils de diff & merge externes pour du XML / JSON et je ne trouve pas de solution élégante.
Dans ce mode-là, l’évol socle à considérer, qui est plus dans l’esprit simplicité, c’est de continuer à améliorer l’outil de merge, en splittant par exemple le merge de la conf en plusieurs étapes spécialisées, et un outil de merge de code au niveau du standard des outils git spécialisés.
En complément, j’ai testé le tweak du registre Windows (sur Windows 11) ça ne semble pas marcher. En tout cas pas en faisant un tar xfz en ligne de commande via la console MINGW32 du Git Windows sur le fichier tar.gz du module…
En phase avec vos analyses.
Cet héritage de MS-DOS (path de 256) limite considérablement les possibilités de Windows même 40 ans après, c’est assez dingue… un argument en faveur de travailler sur MacOS 
Bonne idée, on gagnerait beaucoup en lisibilité.
Effectivement dans les liens identifiés par le(s) parent(s), on pourrait simplifier le nom qui souvent concatène la clé fonctionnelle (enfin ce que retourne le hook getMappedExportPath ne s’en soucie pas).
Il pourrait voir qu’un chemin dépasse 256, et ne pas exporter l’objet/la grappe dans l’arbre.
Mais je trouve que l’export ne serait plus très prédictif en fonction de la taille des (re)nommages.
On peut revoir la définition de l’arbre pour en limiter la profondeur, mais 256 c’est comme tout mettre à 1 ou 2 sous-répertoire de taille variable (les clés sont de 100 char donc ça va vite si on utilise des nommages très longs).
Et pour les liens réflexifs (items de treeview, arbre de groupes…), on finira toujours dans une impasse.
En conclusion :
A date, si on travaille sur Windows = on ne peut pas utiliser le mode éclaté JSON hiérarchique.
Uniquement le mode JSON hirérarchique en fichier unique.
Le mode éclaté déporte le problème de diff d’un modèle relationnel qu’on avait dans “1 gros fichier” dans N répertoires mal ordonnés (ex : on valide l’ajout d’un attribut alors que l’objet est supprimé ailleurs). A la base le besoin de comparer un modèle relationnel (un graph orienté de 100 types d’entité) avec un autre est un problème complexe (que les SGBD ne savent pas faire non plus au niveau DDL).
La solution de parcourir le graph sous forme hiérarchique (arbre) semble plus lisible qu’un mode “flat” comme en XML mais pas généralisable à toutes les interfaces (Windows, ZIP…).
On va devoir revenir à un export plus simple comme en XML = 1 répertoire par type d’objets dans le mode éclaté JSON + N fichiers JSON / 1 par record.
On peut éventuellement garder une vision hiérarchique avec un fichier JSON informatif à la racine qui suit la définition du TreeView mais avec uniquement les champs clés. Mais cela va induire des redondances donc déphasage potentiel d’information si on modifie les fichiers sans passer par Simplicité.
Mon avis :
Qu’en pensez-vous ?
Il va falloir faire un choix.
Indépendamment des discussions sur la structuration de l’arborescence JSON éclatée:
J’ai testé la manipulation de ce format dans WSL (Windows SubSystem for Linux, Ubuntu dans mon cas) et ça semble fonctionner, y compris en travaillant sur un répertoire de module cloné sur un disque Windows (accessible dans WSL dans /mnt) alors que le même répertoire n’est pas utilisable à partir d’une certaine profondeur depuis l’explorateur de fichiers Windows.
Du coup j’ai regardé ce que ça donnait en ligne de commande PowerShell et ça marche.
Et ça semble aussi marcher dans VSCode:
Comme j’ai positionné le flag des paths longs dans la base de registre Windows (cf. mon post précédent) je pense que c’est “juste” que l’explorateur Windows ne gère pas (encore ?) les paths longs alors que les programmes plus modernes comme PowerShell ou VSCode oui.
Bref bienvenue dans le monde merveilleux de Microsoft…
Oui le maillon faible va imposer l’abandon de l’arbre pour le JSON éclaté. ou alors interdire l’usage de Windows, ce qui semble peut envisageable
Pour éviter de gérer des cas particuliers et des transcodages complexes, on va revenir à un export éclaté simple non arborescent (comme en XML).
Ca ne facilitera pas la lecture dans un explorateur, mais ça conviendra très bien pour un usage de merge automatique sur windows.
Par contre on peut garder l’arbre côté UI pour un affichage hiérarchique du module / faciliter le diff si c’est encore possible de comparer un arbre et des buches…
On va s’en occuper rapidement pour la 5.3.
.
Sans l’arborescence avec arbre nous arrivions à faire des “PR classiques” en relisant le code d’autre dev, cela demandait un peu de process mais c’était “fiable”, là avec le mode simple ce n’est pas possible.
Résultat nous perdons du code et du temps suite à des erreurs de manip. Je ne suis pas certains qu’il faille attendre la 5.3.
Oui comme déjà expliqué, l’export éclaté en JSON pose problème sous Windows qui bride la profondeur de l’arbre/path à 256 (pour compatibilité avec feu MSDOS).
Nous n’avons pas trouvé de solution simple/fiable pour lever cette contrainte sous Windows.
Ce sujet est en cours de dev et sera bien livré en 5.3. On verra pour backporter en 5.2 dans la foulée.
This topic was automatically closed 60 minutes after the last reply. New replies are no longer allowed.
L’évolution a été backportée et sera disponible en 5.2.33 rapidement.
Il faudra “recommiter” vos modules s’ils sont en “fichiers JSON éclatés” avec la nouvelle arborescence moins profonde (à 2 niveaux : module et toutes les entités sous leur module).
Bien sur ce ne sera pas comparable avec des versions plus anciennes puisque l’arborescence n’a plus rien à voir. Nous n’avons pas constaté de problème de path sous windows avec nos modules de test, si et seulement si vous ne dézippez pas l’archive dans un sous répertoire déjà très loin sous Windows.
La révision 5.2.34 embarque le changement de format des exports JSON explosés pour compenser les limitations par défaut de Windows en termes de taille des paths, cf. Simplicité platform revision 5.2.34
@Thierry1 je vous laisse échanger avec @Francois pour plus de détails sur le processus de bascule de l’ancien format JSON explosé et le nouveau.
Effectivement, il faut recommiter vos modules en JSON une fois la 5.2.34 installée car la structure JSON a changé pour ne plus avoir d’arbre, ce qui posait problème sous windows.
Il ne faut pas faire de pool avec le nouveau runtime sur une ancienne arborescence, ça risque de vider votre module car le parcours récursif risque de ne pas retrouver les objets dans l’ancienne structure.
Comme annoncé il y a quelque temps ce sera un breaking change de la V5.3, mais comme vous en aviez besoin en 5.2, il faudra être vigilant sur ce point dès maintenant.
Le répertoire /configuration contient désormais :
<module>.json à la racine/<entity>/<userkey>.json
@Thierry1, avez vous pu tester ce nouveau format d’export ? Quels sont vos retours à son sujet ?
Pour rappel il s’agit d’une évolution que nous avons faite et backportée en 5.2 pour vous. Nous avons donc besoin de savoir si ça résout les pbs que l’ancien format vous posait afin de clore le sujet ou, au contraire, de prévoir de la charge de R&D pour continuer à travailler sur le sujet.
Merci