4D v18 introduces a new architecture for files and folders to keep your deployed macOS package and Windows application folders intact. In a nutshell, the logs folder and all user-based settings, including 4D backup settings, are now stored next to the data file. In fact, the settings exist twice; one next to the structure to use as default settings for new data files, and one beside the data file, storing user changes.
As a result, the folder containing the structure can be read-only, since nothing is modified inside (*). Deployment becomes easier because the structure folder can simply be replaced, nothing within it needs to be copied beforehand.
(*) only in project databases. In binary databases the user & password tables are stored in the structure, so the folder must not be read-only.
Preferences folder is dead, long live the Settings folder
During the conversion to 4D v18, some renaming operations are processed:
-
- the Preferences folder becomes Settings
- the backup settings file becomes backup.4DSettings and is placed inside the Settings folder
- the build application settings file becomes buildApp.4DSettings and is also placed inside the Settings folder
Regardless of whether you’re using an interpreted, compiled, or merged database, these operations are performed automatically when the database is opened. There’s nothing to rewrite in order to benefit from these changes, even in deployed applications!
Using Backup files is becoming simpler
In previous 4D releases, the backup settings and backup logs were stored in several files, containing different information.
Now, you can have a backup.4DSettings file near the structure or you can have another one placed in the Settings folder near the data file. The first can be modified with the Structure Settings dialog, the second with the User Settings for data file dialog. Both are dedicated strictly to settings. The one placed in the Settings folder near the structure is to be used as a standard backup, in case your customer forgets to set the User settings for the data file.
How can we take advantage of these mechanisms?
When you deploy your application, it’s recommended to exclude the legacy Preferences folder from your installer so that when you deploy the new version, 4D will automatically apply previous changes. Another good approach for deployment is to create settings dedicated to the data file. The same applies to the backup settings: simply open the user settings of the 4D Dialog data file and adjust the data file backup strategy. You’ll no longer have to worry about backup settings when deploying updates!
And what happened?
The new backupHistory.json file (which can easily be handled using File (Backup history file)) contains a collection of all of the available backup reports. Comprehensive information including start and end timestamps, status, duration, paths, embedded files, and so on. The last backup duration can also easily retrieved using:
GET BACKUP INFORMATION (Last Backup information;$duration;$timestamp)
Note that we also kept the backup log file stored in the Logs folder for easier verification.
Logs Folder
To prevent writing logs in a macOS package or the Windows Program Files folder, we’ve moved the Logs folder near the data file. Since verifying, compacting and repairing operations can be executed without an active data file, the corresponding generated log files are placed in the system user preferences folder. We recommend that you use the following commands to easily manage these files:
File(Compacting log file)
File(Verification log file)
File(Repair log file)
Note that the existing Logs folder is not touched so that you don’t lose files you’ve put in it.
To conclude …
All these improvements have been made to make your deployment easier keep your focus on your development!