Die vier Fälle beim verschachtelten Schreiben

Worum es geht

In einem Request kannst du nicht nur ein Objekt schreiben, sondern auch seine Kinder: die Objekte in seinen Beziehungsfeldern. Eine Firma mit neuen Mitarbeitern anlegen, eine Rechnung mit ihren Positionen ändern, einen Mitarbeiter einer bestehenden Abteilung zuordnen. Das heißt verschachteltes Schreiben.

Für jedes Kind im Request stellt CDMS zwei Fragen:

1. Hat das Kind eine id?
2. Erlaubt die Beziehung das Passende, also das Flag CREATE bzw. UPDATE?

Der Entscheidungsbaum

flowchart TB
    K["Kind im Request"] --> I{"hat eine id?"}
    I -->|nein| C{"Flag CREATE?"}
    C -->|ja| A1["1 · anlegen"]
    C -->|nein| A4["4 · abgelehnt: 400"]
    I -->|ja| E{"gibt es das Objekt?"}
    E -->|nein| A5["404"]
    E -->|ja| U{"Flag UPDATE?"}
    U -->|ja| A2["2 · mitändern"]
    U -->|nein| A3["3 · nur verknüpfen"]

Alle vier Fälle in einem Request

Eine Abteilung, deren Beziehung employees die Flags CREATE und UPDATE hat, und deren Beziehung location keine Flags hat:

PUT /api/rest/department/update/d1…
{
  "data": {
    "id": "d1…",
    "name": "IT",
    "employees": [
      { "firstname": "Ada", "lastname": "Lovelace" },
      { "id": "e2…", "firstname": "Alan", "lastname": "Turing" }
    ],
    "location": { "id": "l7…", "city": "Wiesbaden" }
  },
  "response": ["+"]
}

Ada      → Fall 1: wird angelegt (kein id, CREATE)
Alan     → Fall 2: wird geändert (id, UPDATE)
location → Fall 3: wird nur verknüpft (id, kein UPDATE),
           "city" wird ignoriert

Hätte location ein Kind ohne id, wäre das Fall 4: location hat kein CREATE, die ganze Anfrage scheitert mit 400 recursive-create-not-allowed|location.

Die vier Fälle im Einzelnen

Listen bei PATCH

In einer Liste gelten bei PATCH dieselben vier Fälle wie bei Create und PUT und wie bei einer Einzelreferenz. Anders ist nur, wie ein Kind mit UPDATE geändert wird: PATCH ändert nur die gesendeten Felder, PUT ersetzt das Kind.

Entscheidungstabelle

Bei einem abstrakten Zielmodell braucht ein neues Kind zusätzlich @type, sonst weiß CDMS nicht, welchen Untertyp es anlegen soll. Fehlt er, kommt 400 missing-type-for-abstract-field mit dem Pfad des Feldes: bei PATCH …|mainPhone, bei Create und PUT …|data.mainPhone. Ein unbekannter Typ liefert 400 unknown-type-for-abstract-field|<pfad>|<typ>.

Rollen der Kinder

Jedes Kind, das CDMS anlegt, ändert oder löscht, wird mit den Rollen seines Modells geprüft. Eine Feldrolle am Beziehungsfeld kann die Rolle des Kindmodells ersetzen, aber nur für diesen Weg. Fehlt beides, scheitert die ganze Anfrage mit 403 missing-permission|<rolle>. Siehe Beziehungstypen und Recursive-Flags und Rechte auf Beziehungen (Feldrollen).

Strict Mode aus

Der Strict Mode ist der Standard: Was nicht erlaubt ist, wird mit einem Fehler abgelehnt. Eine Installation kann ihn abschalten. Dann lehnt CDMS weniger ab und lässt stattdessen weg:

Siehe Strict Mode: Fehler oder still ignorieren.

Fallen

Wie es weitergeht

• Was mit Mitgliedern passiert, die in der Liste fehlen: Listen als Zielzustand
• Wer die Gegenseite pflegt: Beide Seiten einer Beziehung
• Die Flags: Beziehungstypen und Recursive-Flags