mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 12:32:43 +00:00
Marc-André Bombeck
a15c6fc553
Seven migrations, 0296 through 0302, apply to an empty database in order and install both triggers. The allocation had been written down as four, and every later document that quoted it inherited a range that had already moved. `scripts/verify-v137-adversarial.ts` is the allocation as a runnable artifact rather than a table somebody keeps in step by hand. It names all seven, refuses a number allocated twice, asserts each trigger is in the migration that claims it, and counts every release inventory against a written-down number instead of against "more than zero" — a list that lost half its entries satisfies a non-empty check and fails this one. It also refuses to report success when it ran no checks at all. It found two things on its first run. Eleven handler entries looked like duplicates because the key ignored the action, and an `[id]` route carries an update and a delete as separate contracts; the key includes the action now. The journey-count leg was then falsified deliberately by expecting nine, which failed on the count and exited non-zero. The `push_attempts` principals are declared optional in the schema and NOT NULL in the database, and that is deliberate rather than drift. The attribution guard is a BEFORE INSERT trigger, so a write omitting both has them filled from the legacy mirror before the constraint is checked; requiring them in the schema would force every established self-delivery writer to name a pair it has no opinion about, and relaxing the columns would let a partial pair reach the table, which is what the trigger refuses. `migrate diff` reports the difference because it cannot see triggers, so the reason is written at the columns and names the test that proves the accommodation still works. Measured rather than assumed: applying trunk's chain to its own empty database reports the same classes of diff — truncated index names, timestamp precision, foreign keys re-stated. The release adds eight lines to that, seven of them in classes trunk already carries and one of them the deliberate pair above.
prisma/
The database layer. HealthLog runs PostgreSQL 16 via Prisma 7. This directory holds the single schema file and the forward-only migration history; the generated client is emitted elsewhere.
Contents
schema.prisma— 61 models, one file.cuid()primary keys,snake_casecolumns via@map(...), encrypted columns mostly suffixed*Encrypted(search the file; there are 24 encrypted column references). Thegenerator clientblock emits to../src/generated/prisma(imported as@/generated/prisma).migrations/— numbered, forward-only SQL migrations (0001_…upward).migration_lock.tomlpins the provider topostgresql.
Migration workflow
# author a migration from a schema edit
pnpm dlx prisma migrate dev --name <short_snake_case_name>
# regenerate the client after any schema change
pnpm dlx prisma generate
Number a new migration with the next free prefix. The production entrypoint runs prisma migrate deploy on boot, so every migration must apply cleanly forward — there is no down-migration path. Always include the migration file in the same change as the schema edit.
Conventions
- Encryption is fail-closed:
*Encryptedcolumns are written through@/lib/crypto(AES-256-GCM, versioned key ids); never store plaintext in an encrypted column. Key rotation isscripts/rotate-encryption-key.ts+docs/ops/encryption-key-rotation.md. - The generated client under
src/generated/prismais build output — do not edit it. - Schema-touching changes that affect the API surface must regenerate
docs/api/openapi.yaml(see../CLAUDE.md).
Related: ../src/lib/README.md (db.ts, rollups/), ../docs/ops/ (migrations + backup runbooks).