Skip to content

ADR-0043: Federated data objects

Kontext

Föderation hing am benannten Schema (schema_definitions.is_federated). Extra-Packs dürfen nicht mehr föderiert sein (ADR-0037). Datensätze von Standard-Datenobjekten waren trotzdem projektgefiltert (entity_records.project_id). Layer und Feature bleiben GIS-projektbezogen (geo_objects.project_id). Nutzer brauchen einen gemeinsamen Datensatz-Pool nur für Datenobjekte im Standard-Schema — und nur in Projekten, die die Entität binden.

Entscheidung

  1. Flag entity_kinds.is_federated (Default false). Erlaubt nur bei management_tab=database und schema_code=standard. Layer/Feature und Projektschemata: 400.
  2. Speicher: föderierte Records liegen im bestehenden Zentral-Pool (entity_records.project_id IS NULL). Kein M:N Record↔Projekt.
  3. Zugriff: ein Projekt sieht und schreibt den Pool, wenn project_schema_kinds die Kind bindet. Liste und Anlage prüfen das Binding; GET/PUT/DELETE /entities/{id} bleibt org-weit für Editoren.
  4. Schreiben ist gemeinsam: eine Änderung gilt in jedem gebundenen Projekt.
  5. Seed-Kinds bleiben false — Katalog-Kopien (ADR-0034) ändern sich nicht. Typwechsel auf Layer/Feature setzt das Flag auf false. Kinder haben ein eigenes Flag.
  6. Umschalten jederzeit. Kein automatisches Zusammenlegen. Alte projektbezogene Zeilen bleiben in der DB, erscheinen aber nicht in der föderierten Liste.
Gate Recommendation Why it fits here Rejected alternative and why
Flag entity_kinds.is_federated Gleiche Stelle wie Typ; kein zweites Zentrum Schema-is_federated — Extra-Packs sind abgelehnt
Speicher project_id IS NULL Zentral-Pool existiert; Index kind_code + project_id Junction Record↔Projekt — doppelter Write-Path
Wer darf Binding in project_schema_kinds „Projekte, die die Entität beinhalten“ Alle Org-Projekte blind
Schreiben Gemeinsames CRUD Live-Share, nicht Übertragung Nur-Lesen / Kopien — das ist ADR-0034
Default false Opt-in; Actor-Sync bleibt Seed actor an — würde Live-Share statt Kopien erzwingen

Begründung (für dieses Setup)

Datenobjekte sind tabellarische Stammsätze, keine GIS-Features. Derselbe Pool (project_id NULL) skaliert über die vorhandene Pagination und die bestehenden Indizes. Bindings sind der schon vorhandene „enthält“-Check. Isolation bleibt die Org-DB (ADR-0032).

Verworfene Alternativen

Alternative Warum verworfen
Föderierte Extra-Schemata (ADR-0036) Global gehört nur ins Standard-Schema
Junction Record↔Projekt Zweiter Write-Path, Dump-Risiko
Alle Standard-Datenobjekte automatisch föderiert Actor-Kopien (ADR-0034) würden still zu Live-Share
Layer/Feature föderieren GIS bleibt geo_objects.project_id

Folgen

  • Alembic 0020_federated_data_objects (Tenant 0008).
  • API: EntityKindIn/Out.is_federated; GET/POST /entities nutzt den Pool, wenn die Kind föderiert ist.
  • UI: Schalter Föderiert nur Standard + Datenobjekt + Org-Admin.