Clarify DB rename acceptance counts

This commit is contained in:
DonVoo 2026-07-14 19:27:28 +02:00
parent 29208b7a41
commit 21844688ac

View file

@ -30,8 +30,10 @@ lautlos, ohne einen einzigen Fehler im Log.
## Teil A — Die Daten umziehen (einmalige Ops-Aktion)
**Ist-Zustand als Baseline (muss danach identisch sein; Stand vor Codex-Umzug):**
`accounts=19`, `copied=215`, `app_users=3`, `jobs=294`
**Ist-Zustand als Baseline (muss danach identisch sein; Jobs duerfen durch
laufende Watch-/Deploy-Laeufe weiterzaehlen):**
`accounts=19`, `copied=215`, `app_users=3`, `jobs=294` vor Ops,
`jobs=296` nach Deploy-Abnahme.
Reihenfolge ist wichtig — **das WAL ist der gefaehrliche Teil**:
@ -53,7 +55,8 @@ sqlite3 $D/emailforwarder.db "PRAGMA wal_checkpoint(TRUNCATE);"
sqlite3 $D/emailforwarder.db "SELECT
(SELECT COUNT(*) FROM accounts), (SELECT COUNT(*) FROM copied),
(SELECT COUNT(*) FROM app_users), (SELECT COUNT(*) FROM jobs);"
# -> MUSS 19|215|3|294 liefern. Wenn nicht: STOPP, nichts weiter tun.
# -> MUSS accounts=19, copied=215, app_users=3 liefern. Wenn nicht: STOPP,
# nichts weiter tun. jobs kann waehrend Watch/Deploy weiterwachsen.
# 5. Erst jetzt umbenennen (ueberschreibt die 0-Byte-Leiche)
mv -f $D/emailforwarder.db $D/mail-graveyard.db