docs: Begründung für trails.current statt active-Flag ergänzen

Die Alternative (bool active auf trail_versions) käme ohne Zirkelbezug aus,
verlagert die Wahrheit aber in N Datensätze: zwei Schreibvorgänge beim
Umschalten, ohne Transaktion kurzzeitig zwei aktive Versionen möglich.
trails.current ändert genau ein Feld und kennt keinen ungültigen Zustand.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Daniel Michelberger 2026-08-06 16:33:58 +02:00
parent f11f7b4dff
commit 564632522e

View file

@ -65,6 +65,18 @@ Die dauerhafte Identität eines Trails.
verträgt das, die Migration muss die Collections aber in zwei Schritten verträgt das, die Migration muss die Collections aber in zwei Schritten
anlegen (siehe „Migration" unten). anlegen (siehe „Migration" unten).
**Warum nicht ein `active`-Flag auf `trail_versions`?** Das wäre ohne
Zirkelbezug ausgekommen, verlagert die Wahrheit aber in N Datensätze statt
einen: Beim Umschalten müssten zwei Versionen geschrieben werden, und ohne
Transaktion kann es kurzzeitig zwei aktive oder gar keine geben. Mit
`trails.current` ändert sich genau ein Feld, und ein ungültiger Zustand ist
nicht möglich. Der Zirkelbezug kostet dafür einen zusätzlichen
Migrationsschritt — einmalig, gegenüber einer Fehlerquelle im Betrieb.
Dass `current` theoretisch auf eine Version eines anderen Trails zeigen
könnte, fängt das Frontend ab: `activate(versionId)` prüft vorher, dass die
Version zum Trail gehört.
### `trail_versions` ### `trail_versions`
Jeder GPX-Upload erzeugt einen Datensatz. Sie werden nie überschrieben. Jeder GPX-Upload erzeugt einen Datensatz. Sie werden nie überschrieben.