Amélioration de la gestion du catalogue pour les systèmes de contrôle des versions

En réponse à vos précieux commentaires, nous avons amélioré l’architecture des projets 4D.

Traditionnellement, le fichier de catalogue contenait toutes les informations relatives à la structure du projet, y compris les informations graphiques telles que les couleurs ou les positions appliquées aux tables, aux champs et aux relations. Désormais, ces informations peuvent être stockées dans un fichier distinct, ce qui simplifie l’examen des pull requests et la gestion des conflits de merge dans les systèmes de contrôle de version.

Penchons-nous sur les spécificités de cette amélioration.

La modification de la position ou de la couleur d’une table, d’un champ ou d’une relation entraînait une mise à jour du fichier catalog.4DCatalog, car il contenait les informations de l’éditeur de structure. Il en allait de même pour la réorganisation des champs d’une table.

À partir de 4D 20 R5, l’apparence graphique des tables et des champs est désormais stockée dans un fichier distinct, placé à côté du fichier de catalogue. Les informations stockées dans le nouveau fichier catalog_editor.json sont les suivantes :

• Position des tables
• Taille des tables
• Couleur des tables
• Nombre de champs affichables des tables
• Ordre des champs des tables
• Couleur des champs
• Position des champs
• Couleur des relations

Grâce à ce nouveau comportement, notamment lorsque plusieurs développeurs travaillent sur le même projet, les modifications de structure apportées par les autres développeurs sont plus faciles à examiner.
Lorsque l’on déplace une table, que l’on redimensionne une table, que l’on change l’ordre des champs ou que l’on change une couleur, le fichier catalog.4DCatalog n’est plus modifié.
Cette nouvelle architecture de fichier facilite la gestion des conflits de fusion dans les applications VCS, puisque le fichier catalog.4DCatalog ne contient plus que des informations cruciales sur la structure de la base de données. Lors de la vérification des pull requests, vous pouvez prêter plus d’attention au fichier catalog.4DCatalog et moins au fichier catalog_editor.json !

Ce nouveau comportement est standard pour les projets créés ou convertis à partir de 4D v20 R5.

IMPACTS sur les projets existants

Comme nous ne voulions pas vous forcer à utiliser ce nouveau comportement pour vos projets existants (créés ou convertis avant 4D v20 R5), nous avons ajouté un nouveau paramètre de compatibilité pour l’activer.
En activant ce paramètre, le nouveau fichier catalog_editor.json sera automatiquement créé lors de la sauvegarde de la structure.

Retour en arrière

En cas d’activation accidentelle, il n’y a pas lieu de paniquer.

L’éditeur de structure charge d’abord les informations du fichier catalog.4DCatalog et les surcharge ensuite par le contenu du fichier catalog_editor.json. Par conséquent, vous pouvez revenir en arrière en désactivant le paramètre de compatibilité, en ouvrant l’éditeur de structure, en effectuant une modification visuelle pour stocker les informations dans le fichier catalog .4DCatalog, puis en supprimant le fichier catalog_editor.json.

Partagez vos réflexions et vos expériences sur notre forum, et faites-nous savoir ce que vous pensez de cette nouvelle fonctionnalité.