Arbeiten mit optimistischer ORDA-Verriegelung

4D v17 stellt vor ORDAORDA ist eine wichtige Entwicklung in 4D, die den 4D Entwicklern eine Welt neuer Möglichkeiten eröffnet. Einer der Vorteile des Einsatzes von ORDA ist das Sperren von Datensätzen, denn ORDA bietet die Wahl zwischen optimistischem und pessimistischem Sperren. Nachdem wir die ORDA-Sperrmechanismen vorgestellt haben, setzen wir die ORDA-Serie fort, damit Sie erfahren, wie Sie mit optimistischem Sperren mit ORDA effizient arbeiten können.

Beispiel: optimistisches Sperren mit ORDA

Optimistisches Sperren in ein paar Worten

Im optimistischen Sperrmodus werden die Datensätze nicht explizit gesperrt , bevor sie aktualisiert werden.

Optimistisches Sperren beruht auf dem Stempel der Datensätze. Jeder Datensatz hat einen internen Stempel, der jedes Mal, wenn ein Datensatz in der Datenbank gespeichert wird, automatisch erhöht wird. Wenn ein Datensatz aktualisiert wurde, seit Sie eine Entität geladen haben, geben die Methoden save(), drop() und lock() einen bestimmten Statuscode zurück, der anzeigt, dass sich der Stempel geändert hat.

REKORDE UND ENTITIES

Zur Erinnerung: Ein Datensatz ist der physische Datensatz in der Datenbank, auf den über eine Entität zugegriffen wird. Eine Entität ist ein Verweis auf einen Datensatz (siehe Abschnitt Entität im Glossar). Datensätze werden über Entitäten gesperrt und entsperrt.

Code-Beispiel

In dem folgenden Beispiel behandeln wir zwei Szenarien, in denen die save() Methode fehlschlägt.

C_OBJECT($status;$employee)

// Get the first employee whose last name is "Smith"
$employee :=ds.Employee.query("lastName=:1"; "Smith").first()
If ($employee#Null)
$employee .lastName:="Wates" // Update employee's last name
$status :=$employee.save() // Save employee
if (Not($status.success)) // The save action fails
Case of
// The record has been updated in database since the entity was loaded
: ($status.status=dk status stamp has changed)
alert ("Jemand hat den Datensatz aktualisiert, seit Sie ihn geladen haben")
//The record is locked by another process
: ($status.status=dk status locked)
alert ("Jemand hat den Datensatz gesperrt")
End case
end if
end if


FALL 1: ENTITÄT HAT SICH GEÄNDERT

Wenn der Datensatz in der Datenbank aktualisiert wurde, seit Sie die Entität geladen haben, wird das zurückgegebene $status Objekt wie folgt aussehen:

{
 "status": 2,
 "statusText": "Stamp has changed",
 "success": false
}

FALL 2: ENTITÄT ist bereits gesperrt

Wenn der Datensatz in der Datenbank bereits durch einen anderen Prozess gesperrt ist, wird das zurückgegebene $status Objekt wie folgt aussehen:

{	 	 
 "status": 3,	 	 
 "statusText": "Already Locked",	 	 
 "lockKind": 1,	 	 
 "lockKindText": "Locked By Record",	 	 
 "lockInfo": {	 	 
     "task_id": 5,	 	 
     "user_name": "Mary Smith",	 	 
     "user4d_id": 1,	 	 
     "host_name": "iMac27-Program6",	 	 
     "task_name": "P_10",	 	 
     "client_version": -1610541312	 	 
 },	 	 
 "success": false	 	 
}

GEMEINSAME Szenarien

Zur Begleitung der save() Methode, ORDA bietet eine sehr nützliche Option: dk auto merge.

dk auto merge versucht, die Aktualisierungen, die in einer im Speicher geladenen Entität vorgenommen wurden, automatisch mit denen zusammenzuführen , die im Datensatz in der Datenbank vorgenommen wurden. Dies kann jedoch fehlschlagen, wenn Sie dieselben Eigenschaften in Ihrer geladenen Entität aktualisiert haben, die ein anderer Benutzer im Datenbankdatensatz aktualisiert hat.

Daher bieten wir zwei Optionen an, um dieses Problem zu lösen.

1- Überschreiben der in der Datenbank durchgeführten Aktualisierungen (OVERRIDE)

In dem folgenden Beispiel wird die save() Methode mit dk auto merge fehl.

Wir sind sicher, dass wir die von einem anderen Prozess in der Datenbank vorgenommenen Aktualisierungen überschreiben wollen.

Diesen Fall können wir wie folgt lösen:

1- Vor dem Speichern verwenden wir die clone() Methode. Dadurch wird ein neuer Verweis auf unsere aktualisierte Entität erstellt. Es ist nützlich, eine Kopie einer Entität zu erstellen, um sie später wieder zu verwenden.

Wenn die save() Methode fehlschlägt, müssen wir:

2- Wir verwenden die Methode reload()-Methode, um unsere Entität aus dem Datenbankeintrag neu zu laden, damit wir einen aktuellen Stempel erhalten.

3- Wir verwenden die geklonte Entität und führen unsere Aktualisierungen erneut durch.

4- Wir speichern die Entität erneut und testen den zurückgegebenen Status.

C_OBJECT($status;$employee;$clonedEmployee)
// Get the first employee whose last name is "Smith"
$employee :=ds.Employee.query("lastName=:1"; "Smith@").first()

If ($employee#Null)
// Update the last name
$employee .lastName:="Dunaway"
// Clone the loaded entity
$clonedEmployee :=$employee.clone()
// Save the entity with auto merge option
$status :=$employee.save(dk auto merge)
// The save action fails
While (Not($status.success))
// The auto merge failed
If ($status.status=dk status automerge failed)
// Reload the entity. The stamp will be updated
$employee .reload()
// Reapply the update on last name
$employee .lastName:=$clonedEmployee.lastName
// Save the entity
$status :=$employee.save(dk auto merge)
End if
End while
End if


2- ERSTELLEN EINER BENUTZERINTERFACE ZUR MANUELLEN VERWALTUNG VON KONFLIKTEN ZWISCHEN EINTRÄGEN UND REKORDEN

ORDA stellt nützliche Methoden zur Verfügung, die Ihnen helfen, eine Schnittstelle zu erstellen , die es den Benutzern ermöglicht, zwischen ihren Aktualisierungen und anderen gleichzeitig durchgeführten Arbeiten zu wählen.

Hier ist ein kurzer Überblick über diese Methoden. Weitere Einzelheiten finden Sie in der Dokumentation.

• touchedAttributes() method: gibt die Attribute zurück, auf die zugegriffen wurde, seit Sie eine Entität geladen oder gespeichert haben.
• diff() Methode: vergleicht zwei Entitäten

In der mitgelieferten HDI sehen Sie, wie Sie eine solche Schnittstelle aufbauen können.