Skip to content

ADR-0041: One-level kind hierarchy and abstract parents

  • Status: accepted
  • Datum: 2026-09-01
  • Phase: Web Schema-CMS
  • Bezug: ADR-0028, ADR-0033

Kontext

Kinds können über parent_code Felder erben (ADR-0028, max. Tiefe 8). Die Web-UI hat das nicht angeboten. Nutzer brauchen Sub-Entitäten in genau einem Schritt — z. B. Akteur → Person / Organisation, Produkt → Querung / VAO — ohne Enkel und ohne Datensätze am Elternteil.

Entscheidung

  1. Genau eine Stufe: ein Kind darf nur eine Wurzel als Elternteil haben. Enkel → 400.
  2. Abstrakt ab dem ersten Kind: is_abstract in der API ist abgeleitet (hat Kinder). Das Elternteil hält Felder; Records und GIS-Inserts darauf → 403. Ein Kind anlegen, während das Elternteil schon Records oder geo_objects hat, verlangt Transfer oder Löschen (ADR-0044; früher 409 ohne Wahl).
  3. Felder bleiben beim Elternteil; Kinder sehen sie als inherited / defined_on (unverändert ADR-0028). Kein Kopieren, kein Override.
  4. UI: Hover über eine Wurzel-Entität fährt Kind anlegen aus; Kinder in der Liste eingerückt. Datensätze nur auf Blatt-Kinds.
  5. Typ vom Elternteil: ein Kind hat immer denselben management_tab wie die Wurzel und kann ihn nicht selbst ändern. Wechselt das Elternteil den Typ, ziehen die Kinder mit. Abweichung beim Anlegen oder Ändern des Kindes → 400. Kind eines Projekt-Elternteils nur Projekt; globales Kind unter Projekt-Elternteil → 400.
  6. Seed-Akteur bleibt eine flache Entität mit Typ-Enum. Promote (ADR-0028) bleibt die Ausnahme: es erzeugt ein Layer-/Feature-Kind unter einem Datenobjekt.
Gate Recommendation Why it fits here Rejected alternative and why
Tiefe Hart eine Stufe Passt zum Bedienweg; ER und QGIS bleiben flach Tiefe 8 belassen — versteckte Hierarchien
Abstrakt Abgeleitet aus Kinderzahl Keine Extra-Spalte, kein Drift Explizites is_abstract — zwei Wahrheiten
Anlegen Hover auf der Zeile, dann Kind anlegen Kind gehört zur Entität, nicht zum allgemeinen + Dauerhaftes ↳ / Elternteil-Select
Typ Identisch zum Elternteil; Wechsel nur dort, dann Kaskade Feature-Kinder bleiben Features; eine Quelle der Wahrheit Freier Kind-Typ oder Eltern-Typ einfrieren

Begründung (für dieses Setup)

Wenige Kinds pro Organisation; Resolve-on-read bleibt billig. Records bleiben auf entity_records.kind_code der Blätter. Das abstrakte Elternteil ist die Produkt-Vorlage, die Kinder die konkreten Kinds.

Verworfene Alternativen

Alternative Warum verworfen
Tiefe 8 weiter erlauben Nutzer wollen einen Schritt; Enkel erschweren Bindings und GIS
Feldkopie aufs Kind Drift gegen ADR-0028
Seed-Akteur jetzt aufbrechen Hybrid/QGIS unberührt lassen; der Mechanismus gilt für neue Kinds
Elternteil-Select im Anlege-Dialog Kind gehört zur Zeile; + legt nur Wurzeln an
Dauerhaftes ↳ auf jeder Wurzel Hover hält die Liste ruhig; Touch zeigt den Text weiter
Kind-Typ frei wählbar Kinder sind Spezialisierungen, keine Umwidmung; Promote bleibt der GIS-Weg
Eltern-Typ nach Kindern einfrieren Typ gehört zur Vorlage; Wechsel am Elternteil aktualisiert die Kinder

Folgen

  • _MAX_KIND_DEPTH = 2 in schema_cms.service; EntityKindOut.is_abstract.
  • Keine Alembic-Migration.
  • ADR-0028 bleibt accepted; die dortige Tiefe 8 ist durch diese ADR ersetzt.