mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 12:32:43 +00:00
Marc-André Bombeck
843c74c98c
Adds AuditLog.actorUserId (migration 0294) and threads it centrally, out of the wide-event context the acting-account resolver already stamps. No call site passes an actor, so no route can forget one. NULL keeps meaning "acted for themselves" — the reading every existing row carries. The threading fills the column only when a request resolved an acting account AND the row is being filed under that account, so a self-action, a refusal, and a delegate's row about themselves all stay NULL rather than acquiring an id that would rewrite what the history says. Delegated reads coalesce to one row per owner, delegate and day, through a partial unique index and an insert that expects to lose the race. The alternative is a row per request on the busiest table in the schema and an activity view made of identical lines. The column carries no foreign key, against the grain of user_id beside it: SET NULL there erases an account from its own history, while here it would turn "the delegate opened this record" into "the owner opened this record". An id that no longer resolves reads as a deleted account; an id that silently became NULL reads as a lie.
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).