ADR-0028: Kind-Vererbung und GIS-Promote

Status: accepted
Datum: 2026-08-27
Phase: Editor Management / Schema-CMS
Bezug: ADR-0025 (Schema-CMS), ADR-0027 (Management tabs), ADR-0010 (geo_objects)

Kontext

Produktarten sollen Kind-Kinds bilden (z. B. Bauprojekte unter Produkt), die Felder der Eltern erben und nur ergänzen dürfen. Aus Stammdaten-Kinds sollen Layer- bzw. Feature-Kinds abgeleitet werden können, die dieselben Attribute tragen; Feature-Kinds müssen in geo_object_kinds landen, damit die Zeichen-Pipeline sie kennt.

Entscheidung

entity_kinds.parent_code (nullable FK, ON DELETE RESTRICT). Die erlaubte Tiefe ist eine Stufe (ADR-0041; früher max. 8).
Feld-Resolve on read: list_fields merged Ahnenkette root→leaf; Response trägt inherited / defined_on. Kinder dürfen Felder nur addieren; Update/Delete geerbter Felder → 403.
POST /entity-kinds/{code}/promote erzeugt Kind mit parent_code=source und management_tab ∈ {layer, feature}. Feature-Promote upsert’t geo_object_kinds (nicht der Meta-Seed feature_type).
Vererbung ohne Feld-Kopie: Parent-Feldänderungen wirken sofort auf Kinder.

Begründung

QGIS-analog (Layer bündelt Features); ein Elternteil hält die Hierarchie simpel. Resolve-on-read vermeidet Drift gegenüber Copy-on-create und erzwingt „geerbte Felder nicht ändern“.

Verworfene Alternativen

Alternative	Warum verworfen
Closure-Table	Overkill bei Tiefe ≪ 10
Copy-on-create der Felder	Drift; widerspricht „nicht ändern/löschen“
Promote nur als Record unter `feature_type`	Keine Kind-Hierarchie / Schema-Erweiterung am abgeleiteten Typ
Mehrfachvererbung / Feld-Override	Komplexität ohne aktuellen Bedarf

Folgen

Alembic 0010_kind_parent_code.
Editor: Kind-Tree, GIS-Menü (⌖), Kind-anlegen (↳), geerbte Felder read-only.