irrlicht
ba085eff4e
- entry: reply_to/reply_count/last_activity; reply_count bubbelt bis Root
- Hauptfeed nur Roots nach last_activity, Profil-Feed inkl. Antworten
- GET /entry/{pid}/thread (Ahnen+Antworten), GET /e/{pid} Focus-Seite
- Frontend: Antworten-Link im Feed, entry.html/entry.js Focus-Seite
- notes/migrations.md: ALTER TABLE fuer Prod
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.7 KiB
Datenbank-Migrationen
Manuelle Schritte, die beim Deploy gegen eine bestehende Datenbank nötig sind.
Eine frische DB (Schema aus db.go) braucht keine davon.
filepath-Sentinel "none" → leerer String
Wann: beim Umstieg auf die Go-Version, falls eine alte kver.db aus der
Python-Zeit weiterverwendet wird.
Hintergrund: Die Python-Version schrieb für Beiträge ohne Bild den
String "none" in entry.filepath. Die Go-Version nutzt stattdessen den
leeren String (Go-Zero-Value) und prüft nur noch auf filepath == "".
Alte "none"-Zeilen würden sonst im Feed als Bildpfad interpretiert
(<img src="/none"> → kaputtes Bild).
Migration:
UPDATE entry SET filepath = '' WHERE filepath = 'none';
Idempotent — kann gefahrlos mehrfach laufen.
Threading-Spalten in entry
Wann: beim Deploy der Threading-Version gegen eine bestehende kver.db, die
die Tabelle entry noch ohne die Threading-Spalten hat.
Hintergrund: Das Threading führt reply_to (pid des Eltern-Posts, 0 = Root),
reply_count (Anzahl Antworten im gesamten Teilbaum) und last_activity
(Sortierschlüssel des Hauptfeeds) ein. CREATE TABLE IF NOT EXISTS ergänzt diese
Spalten bei einer vorhandenen Tabelle nicht.
Migration:
ALTER TABLE entry ADD COLUMN reply_to INTEGER NOT NULL DEFAULT 0;
ALTER TABLE entry ADD COLUMN reply_count INTEGER NOT NULL DEFAULT 0;
ALTER TABLE entry ADD COLUMN last_activity INTEGER;
UPDATE entry SET last_activity = created_at WHERE last_activity IS NULL;
Bestehende Zeilen werden so zu Root-Beiträgen (reply_to = 0, reply_count = 0)
mit last_activity = created_at. Nicht idempotent — die ALTER TABLE-Zeilen nur
einmalig ausführen.