External data storage

A partir de 4D v13, pode escolher onde guardar os dados de cada campo de tipo BLOB, Imagem e Texto. Além das opções de armazenamento internas (no registro ou no arquivo de dados), pode optar por armazenar estes campos fora do arquivo de dados. Neste caso, seus dados são guardados como arquivos externos que são gerenciados por 4D e podem ser gerenciados pelas aplicações de terceiros, sempre e quando você tenha a precaução de conservar a integridade dos dados.

Este princípio é transparente para o usuário: o acesso aos dados é o mesmo, independentemente de sua localização.

O armazenamento externo dos dados permite otimizar o funcionamento da aplicação, permitindo por exemplo transportar grandes volumes de dados ou acessar desde o sistema operativo aos textos ou as imagens contidas na base, inclusive quando não está aberta.

O suporte para o armazenamento externo de dados pode ser realizado de duas maneiras:

• Modo automático: Neste modo, 4D cria e gerencia uma pasta por padrão, estruturada em uma forma específica e que contém todos os dados de armazenamento externo. Neste caso, estes dados se administram de maneira transparente e tem as mesmas funções e o funcionamento automático que para os campos armazenados internamente.
  Para ativar este modo automático, você pode:
  
  • Configurar o armazenamento externo no editor de estrutura (parâmetros guardados com a estrutura da base). Esta opção se descreve no Stored in the record.
  • Utilizar o comando SET EXTERNAL DATA PATH com uma cadeia vazia no parâmetro rota (configuração válida para a sessão). 

• Modo personalizado: neste modo, você decide livremente o lugar onde se armazenam os arquivos externos para cada campo e cada registro. Neste caso, 4D conserva unicamente a relação entre o campo e seus dados e alguns dos mecanismos de base de dados já não estão disponíveis.
  O modo personalizado se ativa utilizando o comando SET EXTERNAL DATA PATH e indicando uma pasta (diferente a pasta por padrão) no parâmetro rota.

A seguinte tabela compara as funções e automatizações disponíveis nos modos automático e personalizado:

Data stored outside of the data file are organized according to the following principles:

• For each record, data is stored in an external file named xxx.txt (Text field), xxx.blob (Blob field) or xxx.jpg, xxx.tiff... (Picture field, whose extension depends on the picture type), where xxx is a unique identifier (UUID) managed by 4D. 

• In automatic mode, all external data is placed in a folder named <DatabaseName>.ExternalData where <DatabaseName> is replaced by the name of the database structure file. This folder is placed next to the database data file (.4DD file).
  Within this folder, 4D creates a folder for each table that has external data (named "Table+table number"), then a subfolder for each external field (named "Field+field number"). The first 100 items of the field are stored at the first level of this folder, the following ones are stored in subfolders numbered beginning with "2", with each subfolder containing up to 100 elements. For example, if field No. 5 of table No. 3 in the "Accounting" database is stored outside the data file, the following tree structure is created by 4D:
  Accounting.4DD
  [Accounting.ExternalData]
      Table3
          Field 5
              Data_1B7F3A 56F6544B45951EFA60426D5ABC.txt
              Data_1B7F3A 56F6544B45951EFA60426D5CCC.txt
              ...
              2
                  Data_2ADBFBA478AAE4409DA9C2D13C90A53B.txt
                  Data_32F8A30B87EE7E4BBC802468D553DC43.txt
                  ...

• In custom mode, the name and location of the folder can be set freely and can be specified separately for each field that is stored externally through the SET EXTERNAL DATA PATH command. This setting is not stored in the database structure.

Recording a field into an external file is done when the record is saved to disk (after validation of the transaction if need be):

• If the external file does not exist, it is created;
• If an external file already exists, 4D replaces it with the new one.
  If you want to keep it, you can either specify a different path (using the SET EXTERNAL DATA PATH command), or use the RELOAD EXTERNAL DATA command in order to load the contents of the field into memory from its external file before saving it to disk again. This option is useful when the file was changed by another application after the record was loaded.

The storage place for the data is a local parameter in each database. When synchronizing or replicating data (see Replication via SQL, these parameters may differ between the local database and the remote one. In this case, the storage complies with the parameters of each database; the synchronization or replication does not change them.

For example, if a Picture field in the remote database is normally saved outside of the data file and this same field in the local database is saved in the data file, when replication occurs, any data added to this field in the local database (in the data file) will still be stored outside of the data file in the remote database.

External storage files can be accessed in read/write by applications other than 4D (operating systems, text or graphical editors, and so on). However, this must be done with precaution because it may alter the functioning of the application:

• If an external storage file is deleted, renamed or moved by the operating system or by a third-party application, 4D considers that the corresponding field has the Null value and the file will be created again (if it is not Null) when the record is saved.
• If you use indexes and the storage files are changed by a third-party application without the parent records being rewritten to disk, the indexes will not be updated.

Note: External Text files are saved in UTF-8 without BOM format. If they are opened by a third-party application and then saved with a BOM, they can still be opened again by 4D but will then be saved without BOM.

Note that loading a record in "read only" does not lock the external files for the fields of this record. These files can still be modified on disk by 4D or by third-party applications, even though their contents are loaded in memory by 4D.