Drizzle migration set is incomplete — 0000 does ALTER on tables that don't exist #85

New issue

Closed

opened 2026-09-14 04:38:41 +00:00 by Mark · 0 comments

Mark commented

2026-09-14 04:38:41 +00:00

Owner

Where: api/drizzle/0000_design_columns_and_indexes.sql, api/drizzle/meta/_journal.json, api/src/db/schema.ts.

Bug:

api/drizzle/meta/_journal.json lists exactly one migration: 0000_design_columns_and_indexes.
That migration's first line is ALTER TABLE "designs" ADD COLUMN "folder_id" uuid; (0000_design_columns_and_indexes.sql:1).
The designs table is never created. api/src/db/schema.ts:10-22 declares it via pgTable('designs', {...}) — drizzle-kit reads that file for the schema — but the migration 0000_*.sql contains no CREATE TABLE.
Same problem for users and exports (schema.ts:3-8, 24-32).
Running npm run db:migrate against a fresh Postgres: fails with relation "designs" does not exist.

Fix consistent with existing patterns:
Regenerate the migration set so 0000 contains the CREATE statements and subsequent ALTERs become their own numbered files.

Stop checking in the current broken 0000_design_columns_and_indexes.sql and its meta snapshot.

With a live Postgres (the migration target is local dev), run from a clean state:

cd api
npm run db:generate   # reads src/db/schema.ts, emits ./drizzle/0000_<name>.sql with CREATE TABLE for users, designs, exports
npm run db:migrate    # apply

If the existing ALTER TABLE designs ADD COLUMN... lines must persist (i.e. they were hand-edited to add columns not in schema.ts), port those into schema.ts first so the regenerated 0000 includes them, then split any post-0000 changes into 0001_*.sql files generated by drizzle-kit.
Verify: drop the DB, npm run db:migrate from clean — succeeds; psql -c '\d designs' shows the columns from both the schema and the original ALTER set.

Acceptance: a fresh Postgres boots, migrations apply without error, and the designs table contains every column the schema + the original ALTER set describe.

**Where:** `api/drizzle/0000_design_columns_and_indexes.sql`, `api/drizzle/meta/_journal.json`, `api/src/db/schema.ts`. **Bug:** - `api/drizzle/meta/_journal.json` lists exactly one migration: `0000_design_columns_and_indexes`. - That migration's first line is `ALTER TABLE "designs" ADD COLUMN "folder_id" uuid;` (`0000_design_columns_and_indexes.sql:1`). - The `designs` table is never created. `api/src/db/schema.ts:10-22` declares it via `pgTable('designs', {...})` — drizzle-kit reads that file for the schema — but the migration `0000_*.sql` contains no `CREATE TABLE`. - Same problem for `users` and `exports` (schema.ts:3-8, 24-32). - Running `npm run db:migrate` against a fresh Postgres: fails with `relation "designs" does not exist`. **Fix consistent with existing patterns:** Regenerate the migration set so `0000` contains the CREATE statements and subsequent ALTERs become their own numbered files. 1. Stop checking in the current broken `0000_design_columns_and_indexes.sql` and its meta snapshot. 2. With a live Postgres (the migration target is local dev), run from a clean state: ```bash cd api npm run db:generate # reads src/db/schema.ts, emits ./drizzle/0000_<name>.sql with CREATE TABLE for users, designs, exports npm run db:migrate # apply ``` 3. If the existing `ALTER TABLE designs ADD COLUMN...` lines must persist (i.e. they were hand-edited to add columns not in `schema.ts`), port those into `schema.ts` first so the regenerated `0000` includes them, then split any post-`0000` changes into `0001_*.sql` files generated by drizzle-kit. 4. Verify: drop the DB, `npm run db:migrate` from clean — succeeds; `psql -c '\d designs'` shows the columns from both the schema and the original ALTER set. Acceptance: a fresh Postgres boots, migrations apply without error, and the `designs` table contains every column the schema + the original ALTER set describe.