Un datastore est l'objet d'interface fourni par ORDA pour référencer et accéder à une base de données. Un datastore est constitué d'un modèle et à de données :

• Le modèle contient et décrit toutes les dataclasses qui composent le datastore. Il est indépendant de la base de données sous-jacente elle-même.
• Les données se réfèrent à l'information qui va être utilisée et stockée dans ce modèle. Par exemple, les noms, adresses et dates de naissance des employés sont des éléments de données que vous pouvez utiliser dans un datastore.

Lorsqu'il est géré via le code, le datastore est un objet dont les propriétés sont toutes les dataclasses définies. Un datastore ne fait référence qu'à une seule base de données locale ou distante.

4d vous permet de gérer les datastores suivants :

• le datastore local, basé sur la base 4D courante, retourné par la commande ds (le datastore principal).
• une ou plusieurs datastores distantes, exposées en tant que ressources RESET dans des bases 4D distantes, retournées par la commande Open datastore.

Note : Les méthodes et les propriétés associées au Datastore sont détaillées dans le chapitre ORDA - DataStore du manuel Langage.

Un datastore exposé sur une application 4D Server est accessible simultanément via différents clients :

• Les applications distantes 4D utilisant ORDA pour accéder au datastore principal à l’aide de la commande [#cmd id = "1482" /]. A noter que l'application distante 4D peut toujours accéder à la base de données en mode classique. Ces accès sont remis par le serveur d'applications 4D.
• D'autres applications 4D (4D Remote, 4D Server) ouvrant une session sur le datastore distant via la commande [#cmd id = "1452" /]. Ces accès sont transmis par le serveur HTTP REST.
• Requêtes 4D for iOS pour la mise à jour des applications iOS. Ces accès sont remis par le serveur HTTP.

Lorsque vous appelez un datastore à l'aide de la commande ds ou Open datastore, 4D référence automatiquement chaque table et champ exposé de la base de données 4D correspondante en tant qu'attributs de l'objet retourné :

• Les tables correspondent aux dataclasses.
• Les champs correspondent aux attributs de stockage (storage attributes)
• Les enregistrements correspondent à des entités.
• Les relations correspondent aux attributs relationnels - les noms des liens, dans l'éditeur de structure, sont utilisés comme noms d'attributs relationnels.
  

Les règles suivantes sont appliquées lors de la conversion :

• Seuls les champs et les tables ayant la propriété "Exposer avec le service REST" sont disponibles.
• Les noms des tables, des champs et des liens sont utilisés comme noms de propriétés d'objet. Si vous souhaitez utiliser la notation à point dans ORDA, assurez-vous que ces noms soient conformes aux règles générales de dénomination des objets, comme expliqué dans la section Identifiants de propriétés d'objets.
  Note : La propriété "Manuel" ou "Automatique" des liens n'a aucun effet dans ORDA.
• Un datastore référence uniquement les tables avec une seule clé primaire (voir Clé primaire). Les tables suivantes ne sont pas référencées :
  
  • Les tables sans clé primaire
  • Les tables avec des clés primaires composites.
• Les attributs de type BLOB ne sont pas gérés dans le datastore. Les attributs de type BLOB sont renvoyés comme Null dans les entités et ne peuvent pas être assignés.

Toute modification apportée à la structure de la base invalide la couche courante de données ORDA. Ces modifications incluent :

• l'ajout ou la suppression d'une table, d'un champ ou d'une relation
• le renommage d'une table, d'un champ ou d'une relation
• la modification d'une propriété principale d'un champ (type, unique, index, autoincrement, valeur null)

Lorsque la couche courante de données ORDA est invalidée, elle est automatiquement rechargée et mise à jour dans les prochains appels du datastore local ds vers 4D et 4D Server. A noter que les références existantes vers des objets ORDA tels que des entités ou des sélections d'entités continueront d'utiliser les données à partir desquelles elles ont été créées, et ce jusqu'à ce qu'elles soient regénérées.

Toutefois, la couche de données ORDA mise à jour n'est pas automatiquement disponible dans les contextes suivants :

• une application 4D distante connectée à 4D Server -- l'application distante doit être reconnectée au serveur.
• un datastore distant (ouvert à l'aide de Open datastore, voir ci-dessous) -- une nouvelle session doit être ouverte.

Lorsque vous travaillez avec un datastore distant référencé par des appels à la commande Open datastore, la connexion entre les process qui effectuent la requête et le datastore distant est gérée par des sessions.

Lorsqu'une application 4D (c'est-à-dire un process) ouvre un datastore externe à l'aide de la commande Open datastore, une session est créée sur le datastore distant pour gérer la connexion. Cette session est identifiée à l'aide d'un identifiant de session interne, associé au localID de l'application 4D. Cette session gère automatiquement l'accès aux données, aux sélections d'entités ou aux entités.

Le localID est local à la machine qui se connecte au datastore distant, ce qui signifie :

• Que si d'autres process de la même application doivent accéder au même datastore distant, ils peuvent utiliser le même localID et partager alors la même session.
• Que si un autre process de la même application ouvre le même datastore distant, mais avec un autre localID, il créera une nouvelle session sur le datastore distant.
• Que si un autre poste se connecte au même datastore distant avec le même localID, il créera une autre session avec un autre cookie.

Ces principes sont illustrés dans les graphiques suivants:

Les process qui gèrent les sessions d'accès aux datastore apparaissent dans la fenêtre d'administration de 4D Server :

• nom : "Gestionnaire REST: <nom du processus>"
• type : type Worker Server HTTP 
• session : le nom de session est le nom d'utilisateur passé à la commande Open datastore.

Dans l'exemple suivant, deux process sont en cours d'exécution pour la même session :

Les fonctionnalités ORDA relatives au verrouillage d'entité et aux transactions sont gérées au niveau du process dans les datastore distants, tout comme en mode client/serveur ORDA :

• Si un process verrouille une entité à partir d'un datastore distant, l'entité est verrouillée pour tous les autres process, même lorsque ces process partagent la même session (voir Verrouillage d'entités). Si plusieurs entités pointant vers le même enregistrement ont été verrouillées dans un processus, elles doivent toutes être déverrouillées dans le process pour supprimer le verrou. Si un verrou a été mis sur une entité, il est supprimé lorsqu'il n'existe plus de référence à cette entité en mémoire.
• Les transactions peuvent être lancées, validées ou annulées séparément sur chaque datastore distant à l'aide des méthodes dataStore.startTransaction( ), dataStore.cancelTransaction( ), et dataStore.validateTransaction( ). Elles n’ont pas d’impact sur les autres datastore.
• Les commandes classiques du langage 4D (START TRANSACTION, VALIDATE TRANSACTION, CANCEL TRANSACTION) s'appliquent uniquement au datastore principal (renvoyé par ds).
• Si une entité d'un datastore distant est verrouillée par une transaction dans un process, les autres process ne peuvent pas la mettre à jour, même si ces process partagent la même session.
• Les verrous sur les entités sont supprimés et les transactions sont annulées :
  • quand le processus est tué.
  • quand la session est fermée sur le serveur
  • lorsque la session est arrêtée à partir de la fenêtre d’administration du serveur.

Une session est automatiquement fermée par 4D lorsqu'il n'y a pas eu d'activité durant son timeout. Le timeout par défaut est de 60 mn mais cette valeur peut être paramétrée à l'aide du paramètre connectionInfo de la commande Open datastore.

Si une demande est envoyée au datastore distant après la fermeture de la session, elle est automatiquement recréée si possible (licence disponible, serveur non arrêté, etc.). A noter cependant que le contexte de la session des verrous et des transactions est perdu (voir ci-dessus).

L'objet datastore lui-même ne peut pas être copié en tant qu'objet :

Les propriétés du datastore sont toutefois énumérables :