bermudalambandClaude Opus 5
e7fd63c2e6
Infrastructure only. No route is converted, nothing changes at run time. The mirror had already drifted, which settles how it should be maintained. schema.ts was missing item_drafts and upload_links from the moment #222 landed, because the spike pulled into ./drizzle and copied the file into src/ by hand, and nobody had reason to look at the copy for a week. So `out` now points at src/db-drizzle and pull refreshes in place — the copy step that made the drift possible is gone — and tablesFilter excludes pgmigrations, which is node-pg-migrate's bookkeeping and has no business in a model of the application's schema. A stale mirror is worse than no mirror, because Drizzle infers row types from it: a converted query would type-check against a schema the database does not have and fail at run time on a column that does not exist. drizzleSchema.integration.test.ts fails when the two disagree, on tables and on columns. It was checked by removing item_drafts from the mirror and confirming the test fails naming it, rather than trusting a green run on a file that already matched. pull also emits 0000_*.sql and meta/ into `out`, because that directory serves both purposes. Both are gitignored: this project's migration history is backend/migrations, hand-written and mostly prose, and #219 has not chosen otherwise — a stray SQL file in src/ is at best noise and at worst mistaken for real history. db is exported beside pool and shares its connections. Both must work at once, since conversion is file by file across 187 sites; separate pools would make a transaction on one invisible to the other and silently double the configured limits. The generated files are excluded from linting. #261 hand-fixed an unused-parameter warning in schema.ts and this re-pull put it straight back, which is the argument in one line: linting generated code buys a fix the next regeneration undoes. itemFilters.drizzle.ts, which is hand-written, is still linted. CONVENTIONS.md records the sql.param() array trap before anyone hits it — the wrong form type-checks, reads correctly and fails at run time as invalid Postgres — and the reason the adoption is worth doing at all, which is that ${value} emits a bind parameter and there is no way to spell "interpolate this as SQL" by accident. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
3.7 KiB
Drizzle conventions
Decided in #216, landed in #217. Read this before converting a query.
What is in this directory
| File | Owner |
|---|---|
schema.ts |
Generated. drizzle-kit pull output. Do not hand-edit. |
relations.ts |
Generated. Same. |
itemFilters.drizzle.ts |
Hand-written. The #216 spike's conversion of buildItemFilterSql, kept as the worked example. |
CONVENTIONS.md |
This file. |
backend/migrations owns the schema. schema.ts is a read-only mirror of it, and refreshing that mirror is a manual step:
DRIZZLE_DATABASE_URL=postgres://user:pass@localhost:PORT/db npx drizzle-kit pull
Run it against a database with every migration applied, after writing a migration. drizzle-kit pull also emits 0000_*.sql and meta/ into this directory because out serves both purposes; both are gitignored, because this project's migration history is backend/migrations and a stray SQL file here would at best be noise and at worst be mistaken for real history. Whether that stays true is #219.
drizzleSchema.integration.test.ts fails when the mirror and the database disagree, on tables or on columns. That test exists because the drift is silent and already happened: the mirror sat missing item_drafts and upload_links from the moment #222 landed until #217, because the spike had copied it into src/ by hand and nobody had reason to look. A stale mirror is worse than none — Drizzle infers row types from it, so a converted query type-checks against a schema the database does not have and fails at run time on a column that does not exist.
The rule that will bite you: arrays
In a Drizzle sql template, an array interpolates as a placeholder list, not as one array parameter.
// WRONG. Emits ANY(($1, $2)::int[]), which is invalid Postgres.
sql`... WHERE id = ANY(${filters.categoryIds}::int[])`
// RIGHT. Emits ANY($1::int[]).
sql`... WHERE id = ANY(${sql.param(filters.categoryIds)}::int[])`
The wrong form type-checks, reads correctly, and fails at run time. Nothing warns. Across 187 call sites this is exactly the shape of defect that passes review and breaks in production, so sql.param() is required for every array and any converted query taking one needs a test that actually executes it.
The reason this is worth doing
${value} in a Drizzle sql template emits a bind parameter, never text. There is no way to spell "interpolate this value as SQL" by accident: the escape hatch that looks like a plain template literal does not behave like one. Passing "1); DROP TABLE items; --" as a status value puts it in the parameters and not in the SQL.
That makes the #202 invariant — only placeholder indices may be interpolated into a clause — a property of the type system rather than a comment guarded by two mutation tests, and it retires #180's three S2077 hotspots rather than leaving them reviewed and watched. It is the strongest argument for the adoption, and the spike confirmed it is real rather than relocated.
Both drivers run at once
db and pool are exported from src/db.ts and share one pool, deliberately. Conversion is file by file across 187 sites, so most queries will be raw pg for a long time and the two must not open separate connection pools — a transaction on one would be invisible to the other, and the configured limits would silently double.
Not settled
Whether generated migrations replace node-pg-migrate is #219, and nothing here depends on it. The first generated migration after a pull also emitted drops and recreations of the three expression indexes, which needs hand-editing and takes real locks on a large table; and data migrations cannot be generated at all. Do not start generating migrations as a side effect of converting a query.