Ein Datastore (Datenspeicher) ist das von ORDA bereitgestellte Oberflächenobjekt, um auf eine Datenbank zu verweisen und auf deren Modell und Daten zuzugreifen. In 4D v17 ist nur die lokale Datenbank, die vom Befehl ds zurückgegeben wird, als Datastore verfügbar.

Hinweis: Die auf den Datastore bezogenen Methoden und Eigenschaften werden im Kapitel ORDA - DataStore des Handbuchs 4D Programmiersprache beschrieben.

Ein Datastore besteht aus einem Modell und Daten:

• Das Modell enthält und beschreibt alle Dataclasses, aus denen sich der Datastore zusammensetzt. Es ist unabhängig von der zugrunde liegenden Datenbank selbst.
• Daten beziehen sich auf die Informationen, die in diesem Modell verwendet und gespeichert werden sollen. Beispielsweise sind Namen, Adressen und Geburtsdaten von Mitarbeitern Datenteile, mit denen Sie in einem Datastore arbeiten können.

Wenn der Datastore über den Code behandelt wird, ist er ein Objekt, dessen Eigenschaften alle definierten Dataclasses sind. Ein Datastore bezieht sich nur auf eine einzelne lokale oder remote Datenbank.

Der Zugriff auf einen Datastore, der in einer 4D Server Applikation veröffentlicht wird, ist simultan durch verschiedene Clients möglich:

• 4D remote Anwendungen mit ORDA, die über den Befehl ds auf den Haupt-Datastore zugreifen. Beachten Sie, dass die 4D remote Anwendung weiter auf die Datenbank im klassischen Modus zugreifen kann. Diese Zugriffe werden über den 4D Applikation Server verwaltet. 
• Andere 4D Applikationen (4D remote, 4D Server), die über den Befehl Open datastore eine Sitzung auf dem remote Datastore öffnen. Diese Zugriffe werden über den HTTP REST Server verwaltet. 
• 4D for iOS Anfragen zum Aktualisieren von iOS Anwendungen. Diese Zugriffe werden über den HTTP Server verwaltet. 

Der Befehl ds gibt eine Referenz auf den Standard-Datastore der Anwendung zurück. Wenn Sie diesen Befehl aufrufen, weist 4D automatisch jede Tabelle und jedes Feld der 4D Datenbank als Attribute des zurückgegebenen Objekts aus:

• Tabellen werden auf Dataclasses abgebildet
• Felder werden auf Speicherattribute abgebildet
• Datensätze werden auf Entities abgebildet
• Verknüpfungen werden auf Verknüpfungsattribute abgebildet - Verknüpfungsnamen, die im Struktureditor definiert wurden, werden als Attributsnamen der Verknüpfungen verwendet.
  

Die folgenden Regeln werden bei der Konvertierung angewendet:

• Tabellen-, Feld- und Verknüpfungsnamen werden auf Objekteigenschaftsnamen abgebildet. Wenn Sie die "Punktnotation" in ORDA verwenden wollen, stellen Sie sicher, dass diese Namen den allgemeinen Regeln zum Benennen von Objekten entsprechen, wie im Abschnitt Identifier für Objekteigenschaft beschrieben.
  Hinweis: Die Eigenschaft "Manuell" oder "Automatisch" von Verknüpfungen hat keine Auswirkung in ORDA.
• Ein Datastore bezieht sich nur auf Tabellen mit einem einzigen Primärschlüssel (siehe Primärschlüssel). Die folgenden Tabellen werden nicht referenziert:
  • Tabellen ohne Primärschlüssel
  • Tabellen mit zusammengesetzten Primärschlüsseln
• Attribute vom Typ BLOB werden nicht im Datastore verwaltet. Sie werden in Entities als Null zurückgegeben und können nicht zugeordnet werden.

Jede Änderung auf der Strukturebene der Anwendung macht die aktuelle Schicht des ORDA Modells ungültig. Das gilt für folgende Änderungen: 

• Eine Tabelle, Verknüpfung oder ein Feld hinzufügen oder entfernen
• Eine Tabelle, Verknüpfung oder ein Feld umbenennen
• Die Haupteigenschaft eines Feldes ändern (Typ, einmalig, Index, Autoincrement, Unterstützung des Nullwertes)

Wurde die aktuelle Schicht des ORDA Modells ungültig, wird sie in nachfolgenden Aufrufen des lokalen Datastore ds in 4D und 4D Server automatisch neu geladen und aktualisiert. Beachten Sie, dass vorhandene Referenzen auf ORDA Objekte wie Entities oder Entity Selections weiterhin das Modell verwenden, welches sie erstellt hat, bis sie neu generiert werden.

Dagegen ist die aktualisierte Schicht des ORDA Modells in folgenden Kontexten nicht automatisch verfügbar:

• Eine remote an den 4D Server angemeldete 4D Anwendung -- die remote Anwendung muss sich erneut an den Server anmelden. 
• Ein remote Datastore (geöffnet mit Open datastore, siehe unten) -- eine neue Sitzung muss geöffnet werden. 

Wird ein remote Datastore über den Befehl Open datastore angesprochen, wird die Verbindung zwischen den anfragenden Prozessen und dem remote Datastore über Sitzungen verwaltet. 

Öffnet eine 4D Applikation (z.B. über einen Prozess) einen externen Datastore über den Befehl Open datastore, wird im remote Datastore eine Sitzung zum Verwalten der Verbindung erstellt. Sie wird über eine interne Nummer identifiziert, die dem Parameter localID auf der 4D Applikation zugeordnet ist. Diese Sitzung verwaltet automatisch den Zugriff auf Daten, Entity-Selections oder Entities. 

localID gilt für den Rechner, der sich an den remote Datastore anmeldet. Das bedeutet folgendes:

• Müssen andere Prozesse derselben Applikation auf denselben remote Datastore zugreifen, können sie dieselbe localID verwenden und so die gleiche Sitzung nutzen. 
• Öffnet ein anderer Prozess derselben Applikation denselben remote Datastore, jedoch mit einer anderen localID, erstellt er eine neue Sitzung auf dem remote Datastore.
• Meldet sich ein anderer Rechner an denselben remote Datastore mit derselben localID an, erstellt er eine andere Sitzung mit einem anderen Cookie.

Nachfolgende Darstellung zeigt die Funktionsweise:

Prozesse, die Sitzungen für den Datastore-Zugriff verwalten, erscheinen im Fenster 4D Server Administration:

• Name: "REST Handler: <process name>" 
• Typ: HTTP Server Worker
• Sitzung: Sitzungsname ist der Benutzername, der dem Befehl Open datastore übergeben wird.

In diesem Beispiel laufen zwei Prozesse für dieselbe Sitzung:

ORDA Features für Sperrung der Entity und Transaktion werden in remote Datastores auf Prozessebene verwaltet, genauso wie im Client/Server Modus von ORDA:

• Sperrt ein Prozess eine Entity eines remote Datastore, ist die Entity für alle anderen Prozesse gesperrt, selbst wenn sie dieselbe Sitzung gemeinsam nutzen (siehe Entity sperren). Zeigen mehrere Entities, die in einem Prozess gesperrt sind, auf denselben Datensatz, müssen alle Entities im Prozess entsperrt werden, um die Sperrung zu entfernen. Ist eine Entity gesperrt, wird sie entsperrt, wenn es keine Referenz mehr auf diese Entity im Speicher gibt.
• Transaktionen lassen sich über die Methoden dataStore.startTransaction( ), dataStore.cancelTransaction( ) und dataStore.validateTransaction() in jedem remote Datastore separat starten, bestätigen oder abbrechen. Sie haben keinen Einfluss auf andere Datastores.
• Die klassischen Befehle (START TRANSACTION, VALIDATE TRANSACTION, CANCEL TRANSACTION) der 4D Programmiersprache werden nur auf den Haupt Datastore angewendet (zurückgegeben durch ds).
• Wird eine Entity aus einem remote Datastore über eine Transaktion in einem Prozess gehalten, können andere Prozesse sie nicht aktualisieren, selbst wenn diese Prozesse dieselbe Sitzung gemeinsam nutzen.
• Die Sperrung von Entities wird entfernt und Transaktionen werden zurückgefahren:
  • wenn der Prozess gekillt wird.
  • wenn die Sitzung auf dem Server geschlossen wird
  • wenn die Sitzung im Server Verwaltungsfenster gekillt wird.

Eine Sitzung wird automatisch von 4D geschlossen, wenn es während der gesetzten Zeitspanne keine Aktivität gibt. Standardmäßig sind 60 Min eingestellt. Dieser Wert lässt sich über den Parameter connectionInfo des Befehls Open datastore verändern. 

Wird eine Anfrage an den remote Datastore gesendet, nachdem die Sitzung geschlossen ist, wird sie automatisch erneut erstellt, soweit möglich (Lizenz verfügbar, Server ist nicht gestoppt...). Beachten Sie jedoch, dass Sperrungen und Transaktionen von dieser Sitzung verlorengehen (siehe oben). 

Das Datastore-Objekt selbst kann nicht als Objekt kopiert werden:

Die Eigenschaften des Datastore sind dagegen aufzählbar: