Listen als Zielzustand

Worum es geht

Schickst du ein Listenfeld mit, etwa employees an einer Firma, beschreibt die Liste den Zustand danach: Genau diese Mitglieder soll die Liste haben. Die Liste ist also kein „füge hinzu“, sondern ein Zielzustand.

Vorher und nachher

flowchart LR
    subgraph vorher ["vorher: employees"]
      A1[Anna]
      B1[Ben]
      C1[Cem]
    end
    subgraph payload ["im Request"]
      A2["{ id: Anna }"]
      C2["{ id: Cem }"]
      D2["{ firstname: Dora }"]
    end
    subgraph nachher ["nachher: employees"]
      A3[Anna]
      C3[Cem]
      D3["Dora (neu)"]
    end
    vorher --> payload --> nachher

Mitglied	vorher	im Request	nachher
Anna	ja	mit `id`	bleibt
Ben	ja	fehlt	fliegt raus: gelöscht (DELETE-Flag) oder entkoppelt
Cem	ja	mit `id`	bleibt
Dora	nein	ohne `id`	wird angelegt (braucht CREATE)

Was mit einem entfernten Mitglied passiert

Ben fällt aus der Liste

1:n mit DELETE1:n ohne DELETEn:m ohne DELETEn:m mit DELETE

Wann: Die Beziehung employees hat das DELETE-Flag, Ben ist ein abhängiges Kind.

1

CDMS
prüft die Löschrolle des Mitarbeiter-Modells
2

Hook
DELETE-Hooks von Ben laufen
3

CDMS→Database
löscht Ben, mit seinen eigenen abhängigen Kindern und Dateien

Ergebnis: Ben gibt es nicht mehr, read liefert 404.

Wann: Die Beziehung items einer Rechnung hat kein DELETE-Flag, die Positionen sind eigenständig.

1

CDMS→Database
setzt bei der Position das Feld der Gegenseite auf leer, also sponsorInvoice = null
2

CDMS
die Position selbst bleibt bestehen

Ergebnis: Die Position ist entkoppelt: Sie existiert weiter, gehört aber zu keiner Rechnung mehr. Eine Rolle am Positionsmodell braucht das nicht.

Wann: Eine Rolle wird aus groups entfernt, die Beziehung hat kein DELETE-Flag.

1

CDMS→Database
löscht die Zeile in der Verbindungstabelle

Ergebnis: Beide Objekte bleiben, nur ihre Verbindung ist weg.

Wann: Eine Rolle wird aus roles einer Gruppe entfernt, die Beziehung hat das DELETE-Flag.

1

CDMS→Database
löscht die Zeile in der Verbindungstabelle, genau wie ohne Flag

Ergebnis: Die Rolle bleibt, auch für alle anderen Gruppen. An n:m wirkt DELETE nicht, weil das Mitglied weiteren Partnern gehören kann. Siehe Many-to-Many über eine Verbindungstabelle.

Die Liste Schritt für Schritt

Wie CDMS eine Liste abgleicht

1

CDMS
sammelt die ids aller Einträge im Request
2

CDMS
nimmt jedes bisherige Mitglied, dessen id nicht dabei ist, aus der Liste: löschen (DELETE) oder entkoppeln
3

CDMS
Einträge mit id: verknüpfen oder mitändern, je nach Flag und Verb
4

CDMS
Einträge ohne id: neu anlegen, wenn die Beziehung CREATE hat
5

CDMS→Database
speichert alles in einer Transaktion

Wie Einträge mit und ohne id behandelt werden, steht unter Die vier Fälle beim verschachtelten Schreiben.

Leere Liste, fehlende Liste

Was eine Liste im Request bewirkt

Verb	Listenfeld im Request	Ergebnis
PUT	fehlt	alle Mitglieder raus
PUT	`null` oder `[]`	alle Mitglieder raus
PATCH	fehlt	unverändert
PATCH	`null` oder `[]`	alle Mitglieder raus
PUT, PATCH	Teilliste	genau diese Mitglieder
Create	fehlt, `null` oder `[]`	leere Liste

„Raus“ heißt bei jedem Mitglied: löschen mit DELETE-Flag, sonst entkoppeln.

Reihenfolge und doppelte Einträge

Reihenfolge: Eine Liste in CDMS ist eine Menge, ohne Position. Die Reihenfolge im Request wird nicht gespeichert. Beim Lesen bestimmst du sie mit order in der response der Liste, sonst ist sie nicht festgelegt. Siehe Filter in verschachtelten Listen.
Doppelte Einträge: Zwei gleiche Einträge ohne id legen bei Create und PUT zwei Objekte an, bei PATCH eins. Dieselbe id zweimal mit verschiedenen Werten: der letzte Eintrag gewinnt. Schicke jedes Mitglied nur einmal.

Fallen

Wie es weitergeht

Mit und ohne id: Die vier Fälle beim verschachtelten Schreiben
Löschen und Kaskaden: Abhängige Objekte (Kaskaden)
PUT und PATCH: PUT oder PATCH? Die null-Falle