Migrationen

Migration committen

# tapedb.schema.ts bearbeiten, dann
npx tapedb migrate dev --name add_task_priority

migrate dev vergleicht das Schema mit tapedb/schema.snapshot.json und schreibt die nächste nummerierte SQL-Datei – reviewt und committet wie jede ORM-Migration – plus das Bundle, das worker.ts importiert. Das Durable Object jedes Workspace wendet ausstehende Migrationen beim nächsten Wake an, eine Transaktion pro Migration, mit deaktivierten Foreign Keys drumherum und vor dem Commit geprüft. Eine Migration, die eine Zeile auf nichts zeigen lassen würde, rollt zurück.

Regeln

• Ein neues Pflichtfeld braucht .default(...) oder .optional().
• Drops brauchen --accept-data-loss; Renames brauchen --rename old=new oder --rename model.old=new, sonst lesen sie als Drop plus Add.
• Änderungen an Typ, Default oder Referenz bauen die Tabelle neu auf, einschließlich Tabellen, auf die andere Tabellen verweisen: Child-Zeilen behalten ihre Keys und nichts kaskadiert.
• Migrationen deklarieren, was sie geändert haben, damit die Wiederherstellung Logsegmente und Snapshots abspielen kann, die unter einem älteren Schema geschrieben wurden. Nicht deklarierte Drift schlägt geschlossen fehl.

Prüfen und deployen

migrate status listet die committeten Migrationen und meldet, ob das Schema aktuell ist. migrate check schlägt in CI oder einem Pre-Commit-Hook fehl, wenn das Schema Änderungen ohne Migration hat. tapedb deploy weigert sich, eine Dev-Konfiguration oder ein nicht migriertes Schema auszuliefern, und führt danach wrangler deploy aus.

Weiter: Dateien, Presence und Broadcast oder Wiederherstellung verstehen.