Improved Catalog Management in Version Control Systems

In response to your valuable feedback, we’ve significantly improved our 4D project architecture.

Traditionally, the catalog file contained all information regarding project structure, including graphical information such as colors or positions applied to tables, fields, and relations. Now, these details can be conveniently stored in a separate file, simplifying the task of reviewing pull requests and managing merge conflicts in version control systems.

Let’s delve into the specifics of this enhancement.

Changing the position or color of a table, field, or relation resulted in an update to the catalog.4DCatalog file, as it contained the structure editor information. The same applied to reordering table fields.

Starting with 4D 20 R5, the graphical appearance of tables and fields is now stored in a separate file alongside the catalog file. The information stored in the new catalog_editor.json file are:

• Table position
• Table size
• Table color
• Table displayable fields count
• Table fields ordering
• Field color
• Field position
• Relation color

With this new behavior, primarily when several developers work on the same project, structure modifications made by other developers are easier to review.
When one moves a table, resizes a table, changes the field order, or changes any color, the catalog.4DCatalog file is no longer touched.
This new file architecture makes managing merge conflicts in VCS applications easier since the catalog.4DCatalog file now only contains crucial database structure information. When checking pull requests, you can pay more attention to the catalog.4DCatalog file and less to the catalog_editor.json file!

This new behavior is the standard one for projects created or converted from 4D v20 R5.

IMPACTS on existing projects

As we didn’t want to force you to use this new behavior for your existing projects (created or converted before 4D v20 R5), we’ve added a new compatibility parameter to activate it.
By enabling this parameter, the new catalog_editor.json file will be automatically created when the structure is saved.

Rolling back

In the event of accidental activation, there’s no need to panic.

The structure editor first loads the information from the catalog.4DCatalog file and then overrides it with the contents of the catalog_editor.json file. As a result, you can roll back by disabling the compatibility setting, opening the structure editor, making a visual change to store the information in the catalog.4DCatalog file, and then deleting the catalog_editor.json file.

Share your thoughts and experiences on our forum, and let us know what you think of this new feature.