CodamAIDocs
Themafertig

Zyklusschutz

Wie CDMS verhindert, dass sich verschachteltes Lesen oder Schreiben im Kreis dreht.

Ausprägungen
Lesen: so tief wie die responseLesen: A → B → AWildcards bleiben bei der idSchreiben: Rückreferenz wird übersprungenSchreiben: jedes Objekt einmalinternes Feld _reference

Worum es geht

Beziehungen zeigen in beide Richtungen: Die Firma kennt ihre Mitarbeiter, jeder Mitarbeiter kennt seine Firma. Folgt ein Programm blind allen Beziehungen, läuft es im Kreis: Firma → Mitarbeiter → Firma → Mitarbeiter … Das nennt man einen Zyklus.

flowchart LR
    A["Firma"] -->|employees| B["Mitarbeiter"]
    B -->|company| A
    B -.->|"hier hört CDMS auf"| X(("■"))

Beim Lesen: die response ist die Grenze

CDMS folgt einer Beziehung nur, wenn du sie in der response ausbaust. Jede Ebene musst du selbst hinschreiben. Weil deine response endlich ist, ist es auch die Antwort.

Hin und zurück: A → B → A → B
Anfrage
POST /api/rest/group/read/a1…
{
  "response": ["name",
    { "field": "children", "response": ["name",
      { "field": "parent", "response": ["name",
        { "field": "children", "response": ["name"] }
      ] }
    ] }
  ]
}
Antwort
{
  "data": {
    "name": "A",
    "children": [
      { "name": "B",
        "parent": {
          "name": "A",
          "children": [ { "name": "B", "children": null, "parent": null } ]
        }
      }
    ]
  },
  "meta": { "error": false }
}

Du siehst: A und B kommen mehrfach vor. CDMS fasst sie nicht zusammen, sondern liefert jede Ebene so, wie du sie angefordert hast. Auf der letzten Ebene stehen children und parent als null, weil du sie dort nicht mehr angefordert hast.

Wie weit CDMS beim Lesen geht
Wildcards + und *
eine Ebene
  • + liefert keine Beziehungen
  • * liefert Beziehungen nur mit ihrer id
  • kein Ausbau, also auch kein Zyklus
Ausbau mit { field, response }
so tief wie geschrieben
  • jede Ebene steht in deiner response
  • Rückwege wie A → B → A sind erlaubt
  • gleiche Objekte können mehrfach vorkommen

Mehr zum Ausbauen unter Referenzen und Listen ausbauen.

Beim Schreiben: Rückreferenz und jedes Objekt einmal

Auch beim verschachtelten Schreiben könnte CDMS im Kreis laufen: Die Firma schreibt ihre Mitarbeiter, jeder Mitarbeiter hat ein Feld company, das wieder auf die Firma zeigt. Zwei Regeln verhindern das:

PUT auf eine Firma mit Mitarbeitern
  1. 1
    CDMS
    schreibt die Firma und kommt zum Feld employees
  2. 2
    CDMS
    schreibt Anna, ein Kind in employees
  3. 3
    CDMS
    kommt bei Anna zum Feld company, also zurück zur Firma
  4. 4
    CDMS
    überspringt die Rückreferenz: Die Verbindung setzt das Elternobjekt selbst, auf beiden Seiten
  1. Die Rückreferenz wird nicht verfolgt. Von einem Kind aus geht CDMS nicht zurück zum Elternobjekt, sondern setzt die Verbindung von oben. Steht im Kind trotzdem eine Rückreferenz, gewinnt das Elternobjekt. Siehe Beide Seiten einer Beziehung.
  2. Jedes Objekt des Requests wird nur einmal verarbeitet. CDMS markiert dafür intern, welche Objekte es schon bearbeitet hat. Die Markierung steht im internen Feld _reference.

Das Feld _reference

_reference ist ein interner Merker, den CDMS nur während der Verarbeitung eines Requests benutzt. In Leseantworten steht er als "_reference": null.

Umgang mit _reference im Client
SituationWas du tust
in einer Leseantwortignorieren, nicht auswerten
beim Schreibenkannst du es stehen lassen: CDMS verwirft ein mitgeschicktes _reference und setzt seinen eigenen Merker

Der Merker gehört dem Server. Schickst du ein gelesenes Objekt zurück, stört das _reference darin nicht – CDMS nimmt es nicht an. Es zählt also nur, was CDMS während der Verarbeitung selbst setzt.

Fallen

Wie es weitergeht

Quellen im Code und in der Wissensdatenbank
  • CDMS/cdms-system-layer – AbstractLayer.recursiveRead, fetchAndSetModel, fetchAndSetList (Tiefe folgt der response); recursivePrepare (_reference), recursiveUpdate (excludeField), setReference
  • CDMS/cdms-rest-api – Expander (Auflösung der response, Wildcards)
  • CDMS/cdms-integrationtest – Probe gegen Group (parent/children)
  • documentation/30-daten-und-persistenz/03-beziehungen.md
Suchen