Datastore es el objeto de interfaz ofrecido por ORDA para hacer referencia a una base de datos y acceder a su modelo y datos. Un almacén de datos está hecho de un modelo y datos:

• El modelo contiene y describe todas las clases de datos que componen el almacén de datos. Es independiente de la base de datos subyacente en sí.
• Los datos se refieren a la información que se va a usar y almacenar en este modelo. Por ejemplo, los nombres, las direcciones y las fechas de nacimiento de los empleados son datos con los que puede trabajar en un almacén de datos.

Cuando se maneja a través del código, el almacén de datos es un objeto cuyas propiedades son todas las clases de datos definidas. Un datastore hace referencia solo a una única base de datos local o remota.

4D le permite manejar los siguientes datastores:

• el datastore local, based on the current 4D database, basado en la base 4D actual, devuelto por el comando ds (el datastore principal).
• uno o más datastores remotos expuestos como recursos REST en bases 4D remotas, devueltos por el comando Open datastore. 

Nota: los métodos y las propiedades relacionados con el Datastore se detallan en el capítulo ORDA - DataStore del manual de Lenguaje.

Se puede acceder simultáneamente a un datastore expuesto en una aplicación 4D Server a través de diferentes clientes:

• Las aplicaciones remotas 4D que utilizan ORDA para acceder al datastore principal con ayuda del comando ds. Tenga en cuenta que la aplicación remota 4D aún puede acceder a la base de datos en modo clásico. Estos accesos son entregados por el servidor de aplicaciones 4D.
• Otras aplicaciones 4D (4D remoto, 4D Server) que abren una sesión en el datastore remoto vía el comando Open datastore. Estos accesos son entregados por el servidor HTTP REST.
• Peticiones 4D for iOS para actualizar las aplicaciones iOS. Estos accesos son entregados por el servidor HTTP.

El comando ds devuelve una referencia al almacén de datos predeterminado de la aplicación. Cuando se llama a este comando, 4D hace referencia automáticamente a cada tabla y campo de la base de datos 4D como atributos del objeto devuelto:

• las tablas están mapeadas a clases de datos
• los campos se asignan a los atributos de almacenamiento
• los registros se asignan a las entidades
• las relaciones se asignan a atributos de relación: los nombres de relación, definidos en el editor de Estructura, se usan como nombres de atributos de relación.
  

Las siguientes reglas se aplican durante la conversión:

• Los nombres de tablas, campos y relaciones se asignan a nombres de propiedades de objetos. Si desea utilizar la "notación de puntos" en ORDA, asegúrese de que dichos nombres cumplan con las reglas generales de denominación de objetos, como se explica en la sección Identificadores de propiedades de objetos.
  Nota: la propiedad "Manual" o "Automático" de relaciones no tiene efecto en ORDA.
• Un almacén de datos solo hace referencia a tablas con una sola llave principal (consulte Definir o eliminar una llave primaria). Las siguientes tablas no están referenciadas:
  • Tablas sin llave primaria
  • Tablas con llaves primarias compuestas.
• Los atributos de tipo BLOB no se gestionan en el almacén de datos. Los atributos de tipo BLOB se devuelven como Null en las entidades y no se pueden asignar.

Toda modificación aplicada a nivel de la estructura de la base invalida la capa actual del modelo ORDA. Estas modificaciones incluyen:

• agregar o quitar una tabla, un campo o una relación
• cambiar el nombre de una tabla, de un campo o de una relación
• cambiar una propiedad central de un campo (tipo, único, índice, incremento automático, soporte de valor null)

Cuando se invalida la capa actual de datos ORDA, se vuelve a cargar y actualizar automáticamente en las llamadas posteriores del almacén de datos local ds en 4D y 4D Server. Tenga en cuenta que las referencias existentes a objetos ORDA tales como entidades o selecciones de entidades continuarán utilizando el modelo a partir del cual se crearon, hasta que se regeneren.

Sin embargo, la capa de datos ORDA actualizada no está disponible automáticamente en los siguientes contextos:

• una aplicación 4D remota conectada al servidor 4D: la aplicación remota debe volver a conectarse al servidor.
• un almacén de datos remoto (abierto utilizando Open datastore, ver abajo): se debe abrir una nueva sesión.

Cuando trabaja con un datastore remoto referenciado por las llamadas al comando Open datastore, la conexión entre los procesos que efectúan la petición y el datastore remoto se maneja a través de sesiones.

Cuando una aplicación 4D (es decir, un proceso) abre un datastore externo utilizando el comando Open datastore, se crea una sesión en el datastore remoto para manejar la conexión. Esta sesión se identifica utilizando una ID de sesión interna que está asociada al localID en la aplicación 4D. Esta sesión administra automáticamente el acceso a datos, selecciones de entidades o entidades.

El localID es local a la máquina que se conecta al datastore remoto, lo que significa que:

• Si otros procesos de la misma aplicación necesitan acceder al mismo datastore remoto, pueden utilizar el mismo localID y, por lo tanto, compartir la misma sesión.
• Si otro proceso de la misma aplicación abre el mismo datastore remoto pero con otro localID, creará una nueva sesión en el datastore remoto.
• Si otra máquina se conecta al mismo datastore remoto con el mismo localID, creará otra sesión con otra cookie.

Estos principios se ilustran en los siguientes gráficos:

Los procesos que administran las sesiones de acceso al datastore se muestran en la ventana de administración de 4D Server:

• nombre: "REST Handler: <nombre del proceso>" 
• tipo: tipo HTTP Server Worker
  
• sesión: el nombre de sesión es el nombre de usuario pasado al comando Open datastore.

En el siguiente ejemplo, se ejecutan dos procesos para la misma sesión:

Las funcionalidades ORDA relacionadas con el bloqueo de entidades y las transacciones se administran a nivel de proceso en datastores remotos, al igual que en el modo cliente/servidor ORDA:

• Si un proceso bloquea una entidad de un datastore remoto, la entidad se bloquea para todos los demás procesos, incluso cuando estos procesos comparten la misma sesión (ver Bloquear entidades). Si varias entidades que apuntan a un mismo registro se han bloqueado en un proceso, se deben desbloquear todas en el proceso para eliminar el bloqueo. Si se ha colocado un bloqueo en una entidad, el bloqueo se elimina cuando no hay más referencias a esta entidad en la memoria.
• Las transacciones se pueden iniciar, validar o cancelar por separado en cada datastore remoto utilizando los métodos dataStore.startTransaction( ), dataStore.cancelTransaction( ) y dataStore.validateTransaction( ). No afectan a otros datastores.
• Los comandos clásicos del lenguaje 4D (START TRANSACTION, VALIDATE TRANSACTION, CANCEL TRANSACTION) solo se aplican al datastore principal (devuelto por ds).
• Si una entidad de un datastore remoto es bloqueada por una transacción en un proceso, los otros procesos no pueden actualizarla, incluso si estos procesos comparten la misma sesión.
• Los bloqueos en las entidades se eliminan y las transacciones se revierten:
  • cuando se mata el proceso.
  • cuando la sesión se cierra en el servidor
  • cuando la sesión se elimina desde la ventana de administración del servidor.  

4D cierra automáticamente una sesión cuando no ha habido actividad durante su tiempo de espera. El tiempo de espera predeterminado es 60 min, pero este valor se puede modificar utilizando el parámetro connectionInfo del comando Open datastore.

Si se envía una solicitud al datastore remoto después de que se haya cerrado la sesión, se vuelve a crear automáticamente si es posible (licencia disponible, servidor no detenido ...). Sin embargo, tenga en cuenta que el contexto de la sesión con respecto a bloqueos y transacciones se pierde (ver arriba).

El objeto datastore en sí no se puede copiar como un objeto: