4a86790364
1 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| d5e7a9a0b5 |
feat(schema): Phase 6 — VarChar bounds, updatedAt, key index, prisma seed
Schema hardening pass. After reading the onboarding/edit forms I
reconsidered the original 'migrate String? -> DateTime?' suggestion:
the bornDate/passedDate placeholders are 'нпр. 1960' and the column
deliberately accepts imprecise values like '1960', 'early 1990s',
'12 May 1960'. Forcing DateTime? would silently break that feature
and require users to enter exact dates they often don't know. The
responsible fix is to keep the free-text semantics but bound the
column length and document the intent in a schema comment. Future
structured-date queries should add a parallel DateTime? column.
Schema changes (prisma/schema.prisma):
- @db.VarChar bounds added to every string column, sized to match
the existing client-side maxLength / app-constant caps:
User.subdomain -> 32, User.title -> 100, User.description -> 2000,
User.bornDate/passedDate -> 50, User.email -> 255, etc.
Image.url/key -> 255, Image.id/userId -> 30.
AdminUser.username -> 50, passwordHash -> 100.
Code.code -> 12, usedByUserId -> 100 (matches Clerk userId scale).
- Image.key: added @@index('Image_key_idx') to support the
/api/image lookup we tightened in Phase 1 (currently a scan).
- updatedAt added to Image, AdminUser, Code (previously only User).
- Inline schema comment on Code.createdById documenting the existing
onDelete: Restrict behaviour (Prisma default) — the migration does
not change it, just makes the audit-trail intent explicit.
Migration:
- 20260802000000_phase6_schema_hardening/migration.sql: explicit
ALTER TABLE ... SET DATA TYPE VARCHAR(N) statements for every
bounded column; ADD COLUMN updatedAt with DEFAULT CURRENT_TIMESTAMP
(so existing rows back-fill immediately); CREATE INDEX for the
Image.key column; a defensive LEFT() truncation UPDATE for any rows
whose bornDate/passedDate exceed 50 chars (the inputs always capped
at 50 on the client side, so this is belt-and-braces). Will be
applied on next deploy via 'prisma migrate deploy'.
Seed:
- prisma/seed.ts: upserts the SUPER_ADMIN row from env
SUPER_ADMIN_USERNAME + SUPER_ADMIN_PASSWORD_HASH. This resolves
the Phase 1 problem where an env-only super-admin had no row in
AdminUser, which meant the Code.createdById FK prevented them from
ever creating codes. The seed is idempotent and safe to run on
every boot (uses upsert).
- package.json: 'prisma.seed' wired to 'tsx prisma/seed.ts'.
- 'db:seed' npm script also added for manual provisioning.
- tsx added as devDependency (executes TypeScript straight from disk
without pre-build).
|
