Mannu
714909d7ee
Three tables + lifecycle enum for Razorpay subscriptions: - subscription_plans: maps razorpay_plan_id -> grants (price/storage/member/child) - family_subscriptions: per-family sub state mirrored from Razorpay - razorpay_webhook_events: append-only log, razorpay_event_id = idempotency key - subscription_status_enum: mirrors Razorpay's lifecycle states exactly - partial unique index family_live_sub_idx: at most one non-terminal sub/family Notes: - Raw-SQL + Drizzle schema both added (repo uses raw sql`` at runtime; schema file keeps drizzle-kit + type inference working) - child_limit added to plan (not in original handoff) since premium lifts the free 1-baby cap to 3 per product decision - Migration 0012 idempotent; also added to debug-migration hot-apply steps - when=1780100000000 (> last entry, per journal drift rule) Entitlement will sync onto families.tier (Task 3/5) so existing quota.ts guards stay unchanged — these tables are audit + Razorpay state mirror. Co-Authored-By: Claude Opus 4.8 <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 | ||
| 0010_error_events.sql | ||
| 0011_user_phone.sql | ||
| 0012_billing.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.