Mannu
678cf65d70
Migration (0009): notifications table with unique daily/weekly slots, is_read column, metadata JSONB for vaccine info. No more localStorage for read state — syncs across devices. API GET /api/notifications?childId=: - Generates vaccine notifications (upsert, filtered by given vaccines at query time) - log_nudge: if no feed/diaper/sleep logged today after noon IST - memory_nudge: if no photo added to memories today - garment_nudge: if wardrobe < 10 items (once per week slot) - Returns unread first, then recent read, limit 60 API PATCH /api/notifications — mark all read for family+child API PATCH /api/notifications/[id] — mark single notification read Page /notifications: - Fetches from real API (no hardcoded mock data) - Optimistic mark-read on tap, navigates to actionUrl - Colored cards per type (red=vaccine, amber=log, purple=memory, pink=garment) - Unread badge + Mark all read button in sticky header - Legend row at bottom debug-migration: added notifications table CREATE IF NOT EXISTS for hot-apply Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| manual | ||
| meta | ||
| 0000_baseline_prod_2026_05_19.sql | ||
| 0001_wardrobe_tables.sql | ||
| 0002_outfits_table.sql | ||
| 0003_circles.sql | ||
| 0004_circle_invite_email.sql | ||
| 0005_email_verification.sql | ||
| 0006_family_invites_missing_cols.sql | ||
| 0007_subscription_status.sql | ||
| 0008_pediatrician_name.sql | ||
| 0009_notifications.sql | ||
| README.md | ||
Tia — Database Migrations
This folder is source code and is committed to git. It is consumed by the
deploy pipeline (pnpm db:migrate, run on container start — see Dockerfile).
Baseline reset — 2026-05-19
The project's first 16 migrations (0000–0015) plus a manual/ folder were
hand-rolled SQL applied directly via the Dokploy database terminal. They were
never run through Drizzle's migrator, so:
- prod had no
__drizzle_migrationstracking table; - the
drizzle/folder was gitignored, so migration SQL never reached the server; schema.tshad drifted well behind the real production schema.
To fix this we performed a Path A baseline reset:
pg_dumpbackup of prod taken and stored off-server.drizzle-kit pullintrospected the live prod schema (35 tables).src/db/schema/*.tswas rewritten to match prod exactly.- Legacy migrations were archived to
_archived_pre_baseline_2026-05-19/(also retained in git history). - A single fresh baseline —
0000_baseline_prod_2026_05_19.sql— was generated and verified column-for-column against the introspected prod schema. - Prod's
drizzle.__drizzle_migrationstable was created and seeded with one row marking0000_baseline_prod_2026_05_19as already applied, so the migrator treats prod as up-to-date and runs nothing on the next deploy.
Normal workflow from here
# 1. Edit src/db/schema/*.ts
# 2. Generate a migration from the diff:
pnpm db:generate # writes drizzle/000N_<name>.sql
# 3. Review the generated SQL by eye.
# 4. Apply locally against the dev DB:
pnpm db:migrate
# 5. Commit schema + migration together, then push.
# Dokploy redeploys; the migrator applies it in prod on container start.
Hard rules
- Never edit a migration file after it has been pushed. Fix-forward with a new migration instead.
- Never run schema-changing SQL directly against prod. It becomes drift.
- The
drizzle/folder must stay out of.gitignore.
RLS policies
Five log tables (feeds, diapers_logs, sleeps, vaccinations, growth)
plus children / family_members carry row-level-security policies in prod.
These are not modelled in the pgTable definitions and are managed
separately in the database. Drizzle migrations will not recreate them — keep
that in mind if you ever rebuild the DB from scratch.