You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2.4 KiB
2.4 KiB
| title | status | type | priority | created_at | updated_at |
|---|---|---|---|---|---|
| [TRIAGE] Database migration strategy for Cloudflare Workers (startup vs wrangler d1 execute) | completed | task | critical | 2026-03-10T23:32:07Z | 2026-03-10T23:32:07Z |
- Option 3 (SQLx) is ruled out — TRIAGE e8a330 established that SQLx is incompatible with workers-rs/D1.
- Option 1 (startup migration from the Workers handler) is impractical: Workers spin up per-request via V8 isolates. Running DDL before every request adds latency and is fragile.
- Option 2 is the canonical Cloudflare-recommended approach. It is idempotent (
CREATE TABLE IF NOT EXISTS), keeps the Workers handler free of DDL overhead, and integrates cleanly into CI/CD as a post-tofu applystep.
Production: wrangler d1 execute quotesdb --file infra/schema.sql --remote — run once after first tofu apply, and again for each incremental migration file.
Local dev / tests: NativeRepository::run_migrations() (ticket 00aff0) runs execute_batch via rusqlite on native startup. No manual wrangler step needed.
This decision is co-resolved with TRIAGE 5c0c64, which asked the same question from the OpenTofu angle. Both arrive at the same answer.
- Co-resolved with TRIAGE 5c0c64. - Ticket a5049d updated with chosen strategy. - Ticket bb1514 created: implementation plan for `infra/schema.sql`. - Ticket 75489a updated: documents the wrangler workflow. `chore(quotesdb): resolve triage — database-migration-strategy-for-cloudflare-workers-startup-v`