Hooks bei verschachtelten Objekten und Kaskaden

Worum es geht

Eine Anfrage schreibt oft mehr als ein Objekt: eine Firma mit neuen Mitarbeitern, eine Rechnung mit ihren Positionen, ein Löschen, das abhängige Kinder mitnimmt. Jedes dieser Objekte bekommt seine eigenen Hooks, also die Hooks seines Modells, mit seiner Operation.

CDMS führt diese Hooks nicht sofort aus. Während der Rekursion trägt es jedes Objekt in zwei Warteschlangen ein, eine für die Before-Hooks und eine für die After-Hooks. Eine Warteschlange ist eine Liste, die in der Reihenfolge des Eintragens abgearbeitet wird. Erst wenn der ganze Baum durchlaufen ist, arbeitet CDMS sie ab.

Welches Kind welche Hooks bekommt

Die Warteschlange an einem Beispiel

Eine Abteilung hat eine Liste employees. Die Beziehung hat die Flags CREATE, UPDATE und DELETE. Vor der Anfrage gehören Anna und Ben zur Abteilung. Der Client schickt ein PUT:

PUT /api/rest/org/department/update/d-1
{
  "data": {
    "id": "d-1",
    "name": "Vertrieb Nord",
    "employees": [
      { "id": "e-anna", "name": "Anna Berg" },
      { "name": "Cem" }
    ]
  },
  "response": ["id"]
}

200, { "data": { "id": "d-1" }, … }

flowchart TB
    D["Abteilung d-1<br/>UPDATE"] --> A["Anna<br/>UPDATE"]
    D --> C["Cem, neu<br/>CREATE"]
    D -.-> B["Ben, weggelassen<br/>DELETE"]

CDMS geht die Abteilung durch und trägt dabei in die Warteschlangen ein:

Dann arbeitet CDMS die Warteschlangen ab, je Operation in der festen Reihenfolge CREATE, UPDATE, PATCH, DELETE:

Zwischen den beiden Spalten liegen Validierung und Speichern, siehe Die Reihenfolge in einem Schreibvorgang. Innerhalb einer Operation laufen die Before-Hooks in der Reihenfolge des Eintragens, also das Elternobjekt vor seinen Kindern. Die After-Hooks trägt CDMS erst ein, wenn ein Objekt samt Kindern fertig ist. Deshalb laufen dort die Kinder vor dem Elternobjekt.

Die Reihenfolge der Operationen geht vor die Baumstruktur. Im Beispiel läuft der Before-Hook des neuen Kindes Cem vor dem Before-Hook der Abteilung, weil CREATE vor UPDATE drankommt.

Kaskade beim Löschen

Beim DELETE gibt es nur eine Operation. Hier bestimmt der Baum allein die Reihenfolge:

flowchart TB
    F["Firma<br/>before 1 · after 5"] --> A1["Abteilung Nord<br/>before 2 · after 3"]
    A1 --> P1["Team N-1<br/>before 3 · after 1"]
    A1 --> P2["Team N-2<br/>before 4 · after 2"]
    F --> A2["Abteilung Süd<br/>before 5 · after 4"]
    F -.-> K["Kunde, nur abgekoppelt<br/>kein Hook"]

Die Before-Hooks laufen von oben nach unten, die After-Hooks von unten nach oben. Das Elternobjekt sieht in seinem After-Hook also, dass alle Kinder schon behandelt sind.

Wenn die Before-Hooks laufen, hat CDMS die Rekursion schon hinter sich:

• Jedes abhängige Kind ist aus den Beziehungsfeldern seines Elternobjekts genommen und zum Entfernen vorgemerkt. Der Before-Hook der Firma findet ihre Abteilungen nicht mehr in ihrer Liste. Jede Abteilung bekommt dafür ihren eigenen Hook, mit allen ihren Feldern.
• Die Rollen aller Objekte sind geprüft. Fehlt bei einem Kind die Löschrolle, läuft kein einziger Hook.
• Ein Before-Hook, der eine Exception wirft, verhindert das Löschen des ganzen Baums, egal auf welcher Stufe er sitzt.

Entscheidungstabelle

Beim Zurücklesen: READ-Hooks

Nach einem Create, PUT oder PATCH liest CDMS das Objekt mit der response der Anfrage zurück. Jede ausgebaute Referenz und jeder Eintrag einer ausgebauten Liste ist dabei ein eigenes Lesen über das eigene Modell, mit eigenem READ-Hook. Fordert die Antwort im Beispiel employees mit an, laufen die READ-Hooks der Abteilung und jedes Mitarbeiters. Siehe Referenzen und Listen ausbauen.

Fallen

Wie es weitergeht

• Wo die Warteschlangen im Ablauf abgearbeitet werden: Die Reihenfolge in einem Schreibvorgang
• Welche Kinder mitgelöscht und welche nur abgekoppelt werden: Abhängige Objekte (Kaskaden)
• Was passiert, wenn der Hook eines Kindes wirft: Wenn ein Hook scheitert