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:
parent
f11f7b4dff
commit
564632522e
1 changed files with 12 additions and 0 deletions
|
|
@ -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.
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue