4D v18 introduce una nuova architettura per i file e le cartelle per mantenere intatte le cartelle dei pacchetti macOS e delle applicazioni Windows distribuite. In poche parole, la cartella dei registri e tutte le impostazioni basate sull’utente, comprese le impostazioni di backup di 4D, sono ora memorizzate accanto al file di dati. In effetti, le impostazioni esistono due volte: una accanto alla struttura da usare come impostazioni predefinite per i nuovi file di dati e una accanto al file di dati, per memorizzare le modifiche dell’utente.
Di conseguenza, la cartella contenente la struttura può essere di sola lettura, poiché nulla viene modificato al suo interno (*). La distribuzione diventa più semplice perché la cartella della struttura può essere semplicemente sostituita e non è necessario copiare nulla al suo interno.
(*) solo nei database di progetto. Nei database binari le tabelle utenti e password sono memorizzate nella struttura, quindi la cartella non deve essere di sola lettura.
La cartella Preferenze è morta, viva la cartella Impostazioni
Durante la conversione a 4D v18, vengono eseguite alcune operazioni di ridenominazione:
-
- la cartella Preferences diventa Settings
- il file delle impostazioni di backup diventa backup.4DSettings e viene collocato all’interno della cartella Settings
- il file delle impostazioni dell’applicazione di compilazione diventa buildApp.4DSettings e viene anch’esso collocato all’interno della cartella Settings.
Indipendentemente dal fatto che si stia usando un database interpretato, compilato o unito, queste operazioni vengono eseguite automaticamente all’apertura del database. Non c’è nulla da riscrivere per beneficiare di queste modifiche, anche nelle applicazioni distribuite!
L’uso dei file di backup è sempre più semplice
Nelle versioni precedenti di 4D, le impostazioni e i registri di backup erano memorizzati in diversi file, contenenti informazioni diverse.
Ora è possibile avere un file backup.4DSettings vicino alla struttura o un altro file nella cartella Settings vicino al file di dati. Il primo può essere modificato con la finestra di dialogo Impostazioni struttura, il secondo con la finestra di dialogo Impostazioni utente per il file di dati. Entrambi sono dedicati esclusivamente alle impostazioni. Quello collocato nella cartella Impostazioni vicino alla struttura deve essere usato come backup standard, nel caso in cui il cliente dimentichi di impostare le Impostazioni utente per il file di dati.
Come si possono sfruttare questi meccanismi?
Quando si distribuisce l’applicazione, si consiglia di escludere la cartella legacy Preferences dal programma di installazione, in modo che quando si distribuisce la nuova versione, 4D applichi automaticamente le modifiche precedenti. Un altro buon approccio per la distribuzione è quello di creare impostazioni dedicate al file di dati. Lo stesso vale per le impostazioni di backup: basta aprire le impostazioni utente del file di dati di 4D Dialog e regolare la strategia di backup del file di dati. Non dovrete più preoccuparvi delle impostazioni di backup quando distribuite gli aggiornamenti!
E cosa è successo?
Il nuovo file backupHistory.json (che può essere facilmente gestito con il file File (Backup history file)) contiene una raccolta di tutti i rapporti di backup disponibili. Informazioni complete che includono i timestamp di inizio e fine, lo stato, la durata, i percorsi, i file incorporati e così via. La durata dell’ultimo backup può essere facilmente recuperata utilizzando:
GET BACKUP INFORMATION (Last Backup information;$duration;$timestamp)
Si noti che abbiamo anche conservato il file di registro del backup nella cartella Logs per facilitare la verifica.
Cartella Logs
Per evitare di scrivere i registri in un pacchetto macOS o nella cartella dei file di programma di Windows, abbiamo spostato la cartella Logs vicino al file di dati. Poiché le operazioni di verifica, compattazione e riparazione possono essere eseguite senza un file di dati attivo, i corrispondenti file di registro generati sono collocati nella cartella delle preferenze dell’utente del sistema. Si consiglia di utilizzare i seguenti comandi per gestire facilmente questi file:
File(Compacting log file)
File (Verification log file)
File (Repair log file)
Si noti che la cartella Logs esistente non viene toccata, in modo da non perdere i file in essa contenuti.
Per concludere…
Tutti questi miglioramenti sono stati apportati per semplificare la distribuzione e mantenere la concentrazione sullo sviluppo!