irrlicht
cb3da3bb24
- entry.deleted; entrySelect LEFT JOIN + COALESCE(username)
- POST /entry/{pid}/delete: deleted=1, Inhalt/Bild/Autor geleert, Zeile bleibt
- Konto-Löschung soft-deletet die eigenen Beiträge (statt hartem DELETE),
damit fremde Antworten nicht verwaisen
- Frontend: [deleted]-Platzhalter im Feed, Löschen-Button auf Focus-Seite
- notes/migrations.md: ALTER TABLE deleted
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
66 lines
2.2 KiB
Markdown
66 lines
2.2 KiB
Markdown
# 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:**
|
|
```sql
|
|
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:**
|
|
```sql
|
|
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.
|
|
|
|
---
|
|
|
|
## Soft-Delete-Spalte in `entry`
|
|
|
|
**Wann:** beim Deploy der Soft-Delete-Version gegen eine bestehende `kver.db`.
|
|
|
|
**Hintergrund:** Statt Beiträge hart zu löschen werden sie als `[deleted]`-Platzhalter
|
|
markiert (`deleted = 1`, Inhalt/Bild/Autor geleert), damit Antworten nicht verwaisen.
|
|
Das Frontend und die Feeds erkennen gelöschte Beiträge an dieser Spalte.
|
|
|
|
**Migration:**
|
|
```sql
|
|
ALTER TABLE entry ADD COLUMN deleted INTEGER NOT NULL DEFAULT 0;
|
|
```
|
|
|
|
Bestehende Beiträge bleiben damit sichtbar (`deleted = 0`). Nur einmalig ausführen.
|