Kapitel 40 zeigte GEZIELTES Einbetten – dieses Kapitel erklärt, WARUM tasks auf Project BEWUSST NIEMALS eingebettete project-Referenzen zeigen darf.

Das Problem provozieren

Angenommen, project:read:embedded würde SOWOHL auf Project::tasks ALS AUCH auf Task::project gesetzt: Project bettet seine Tasks ein, JEDE eingebettete Task bettet WIEDERUM ihr Project ein, das WIEDERUM seine Tasks einbettet – eine ENDLOSE Verschachtelung.

{
  "id": 1,
  "tasks": [
    {"id": 1, "project": {"id": 1, "tasks": [{"id": 1, "project": { /* ... unendlich ... */ } }]}}
  ]
}

Die Lösung: getrennte embedded-Gruppen

Kapitel 40 nutzte BEREITS die richtige Strategie, hier NOCHMALS EXPLIZIT: Task::project bekommt task:read:embedded, Project::tasks bekommt KEINE entsprechende Embedded-Gruppe für project:read:embedded – die Einbettung ist damit RICHTUNGSGEBUNDEN, NIEMALS beidseitig.

// Project.php - tasks bleibt bewusst NUR project:read (Kapitel 38), NIE embedded
#[Groups(['project:read'])]
private Collection $tasks;

// Task.php - project darf embedded werden (Kapitel 40)
#[Groups(['task:read', 'task:write', 'task:read:embedded'])]
private ?Project $project = null;

Die Eselsbrücke: Baum, kein Kreis

Beziehungen sollten sich als BAUM denken lassen, NICHT als Kreis: Project → Task → Tag ist eine EINDEUTIGE Richtung. Sobald eine Einbettung ZURÜCK zum Ausgangspunkt führen würde, ist eine IRI (statt Embedding) die RICHTIGE Wahl.

maxDepth als zusätzliche Absicherung

#[Groups(['task:read', 'task:write', 'task:read:embedded'])]
#[\Symfony\Component\Serializer\Annotation\MaxDepth(1)]
private ?Project $project = null;

MaxDepth ist ein ZUSÄTZLICHES Sicherheitsnetz (erfordert enable_max_depth: true im normalizationContext) – SELBST wenn die Gruppen-Konfiguration versehentlich einen Zyklus zuließe, würde die Verschachtelungstiefe HART begrenzt.