4D v18 introduz uma nova arquitectura para ficheiros e pastas para manter intactos o seu pacote MacOS implantado e as pastas de aplicações Windows. Em resumo, a pasta de registos e todas as configurações baseadas no utilizador, incluindo as configurações de backup 4D, são agora armazenadas ao lado do ficheiro de dados. De facto, as definições existem duas vezes; uma junto à estrutura para utilizar como definições padrão para novos ficheiros de dados, e outra ao lado do ficheiro de dados, armazenando as alterações do utilizador.
Como resultado, a pasta contendo a estrutura pode ser apenas de leitura, uma vez que nada é modificado no interior (*). A implantação torna-se mais fácil porque a pasta da estrutura pode simplesmente ser substituída, nada dentro dela precisa de ser copiado de antemão.
(*) apenas em bases de dados de projectos. Nas bases de dados binárias, as tabelas de utilizadores e palavras-passe são armazenadas na estrutura, pelo que a pasta não deve ser apenas de leitura.
A pasta Preferências está morta, viva a pasta Configurações
Durante a conversão para 4D v18, algumas operações de renomeamento são processadas:
-
- a pasta Preferências torna-se Definições
- o ficheiro de definições de cópia de segurança torna-se cópia de segurança.4DSettings e é colocado dentro da pasta Settings
- o ficheiro de definições da aplicação build torna-se buildApp.4DSettings e é também colocado dentro da pasta Settings
Independentemente de estar a utilizar uma base de dados interpretada, compilada, ou fundida, estas operações são realizadas automaticamente quando a base de dados é aberta. Não há nada a reescrever para poder beneficiar destas alterações, mesmo em aplicações implantadas!
A utilização de ficheiros de Backup está a tornar-se mais simples
Em versões 4D anteriores, as configurações de backup e os registos de backup eram armazenados em vários ficheiros, contendo informações diferentes.
Agora, pode ter um ficheiro de backup.4DSettings perto da estrutura ou pode ter outro colocado na pasta Settings perto do ficheiro de dados. O primeiro pode ser modificado com a caixa de diálogo Configurações da estrutura, o segundo com a caixa de diálogo Configurações do utilizador para ficheiro de dados. Ambas são dedicadas estritamente às definições. A que é colocada na pasta Definições perto da estrutura deve ser usada como cópia de segurança padrão, no caso do seu cliente se esquecer de definir as Definições do Utilizador para o ficheiro de dados.
Como podemos tirar partido destes mecanismos?
Ao implementar a sua aplicação, recomenda-se excluir a pasta de Preferências herdadas do seu instalador para que, ao implementar a nova versão, 4D aplique automaticamente as alterações anteriores. Outra boa abordagem para a implantação é a criação de definições dedicadas ao ficheiro de dados. O mesmo se aplica às definições de backup: basta abrir as definições do utilizador do ficheiro de dados 4D Dialog e ajustar a estratégia de backup do ficheiro de dados. Já não terá de se preocupar com as definições de cópia de segurança ao implementar as actualizações!
E o que aconteceu?
O novo ficheiro de salvaguardaHistory.json (que pode ser facilmente manuseado utilizando File (Backup history file))) contém uma colecção de todos os relatórios de segurança disponíveis. Informação abrangente, incluindo carimbos temporais de início e fim, estado, duração, caminhos, ficheiros incorporados, e assim por diante. A última duração da cópia de segurança também pode ser facilmente recuperada utilizando:
GET BACKUP INFORMATION (Last Backup information;$duration;$timestamp)
Note que também mantivemos o ficheiro de registo de cópia de segurança armazenado na pasta Logs para uma verificação mais fácil.
Pasta de Registos
Para evitar a escrita de registos num pacote macOS ou na pasta Ficheiros de Programas do Windows, movemos a pasta de Registos para perto do ficheiro de dados. Uma vez que as operações de verificação, compactação e reparação podem ser executadas sem um ficheiro de dados activo, os ficheiros de registo gerados correspondentes são colocados na pasta de preferências do utilizador do sistema. Recomendamos que utilize os seguintes comandos para gerir facilmente estes ficheiros:
File(Compacting log file)
File (Verification log file)
File (Repair log file)
Note que a pasta de Logs existente não é tocada para que não se percam ficheiros que se tenham colocado nela.
Para concluir …
Todas estas melhorias foram feitas para facilitar a sua implementação, mantenha o seu foco no seu desenvolvimento!