StefanMoCoAt
dbe7c74a9c
- Add database schema documentation: `Database_Schema_V1-V009.md` for tenant-isolated entities (`veranstaltungen`, `turniere`, `bewerbe`, etc.). - Draft initial Kassa API reference: `Kassa_API.md` (status: DRAFT). - Finalize Stammdaten API reference: `API_Uebersicht_Stammdaten.md` (status: ACTIVE). - Summarize tenant isolation and multi-tenant strategy in `Multi_Tenant_Kurz.md`. - Update `README.md` with links to new references. Mark B-2 roadmap tasks as partially complete.
29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
---
|
||
type: Reference
|
||
status: ACTIVE
|
||
owner: Lead Architect
|
||
last_update: 2026-04-03
|
||
---
|
||
|
||
# Tenant-Isolation & Multi‑Tenant (Kurzfassung)
|
||
|
||
Vollständige Entscheidung: [ADR‑0021: Tenant‑Resolution‑Strategie (Schema‑per‑Tenant)](../01_Architecture/adr/0021-tenant-resolution-strategy-de.md).
|
||
|
||
## Kernaussagen
|
||
|
||
- Eine Veranstaltung = ein Tenant = ein Datenbankschema (Schema‑per‑Tenant).
|
||
- Requests tragen `X-Event-Id`; Backend validiert gegen `control.tenants` und schaltet das Schema je Request.
|
||
- Flyway führt Migrationen je Tenant‑Schema aus (eigene `flyway_schema_history`).
|
||
- Stammdaten (Reiter/Pferde/Vereine/Funktionäre) sind global und nicht tenant‑spezifisch; Entries/Kassa sind tenant‑lokal.
|
||
|
||
## Umsetzung (Kurz)
|
||
|
||
- Web‑Layer: `TenantWebFilter` (Spring) bzw. Plugin (Ktor) liest `X-Event-Id` und legt `TenantContext` ab.
|
||
- Persistence: SCHEMA‑Multitenancy (`SET search_path`) oder Hibernate‑`MultiTenantConnectionProvider`.
|
||
- Registry: `control.tenants(event_id, schema_name, status, db_url?, version, created_at)`.
|
||
|
||
## Betroffene Bereiche
|
||
|
||
- Datenmodell tenant‑lokal: `veranstaltungen`, `turniere`, `bewerbe`, `abteilungen`, `teilnehmer_konten`, `turnier_kassa` (siehe [Datenbankschema](./Schema/Database_Schema_V1-V009.md)).
|
||
- Services: Der Entries‑Service arbeitet mandantenfähig; andere Services bleiben Single‑Tenant/global (vgl. Backend‑Roadmap).
|