This project uses two database ORMs: Prisma and TypeORM. Both require proper migration management for safe schema evolution.
- Prisma: Used for main application models (User, Project, Notification, etc.)
- TypeORM: Used for insurance-related entities (InsurancePolicy, Claim, InsurancePool, ReinsuranceContract)
Create a new migration:
npm run prisma:migrate:generate -- add_user_emailThis will:
- Detect changes in
prisma/schema.prisma - Generate SQL migration file in
prisma/migrations/ - Apply migration to your local database
Reset database (WARNING: Deletes all data):
npm run prisma:migrate:resetOpen Prisma Studio to view/edit data:
npm run prisma:studioDeploy pending migrations:
npm run prisma:migrate:deployThis applies migrations without modifying the migration history.
Generate a new migration from entity changes:
npm run typeorm:migrate:generate -- -n AddPolicyFieldsThis creates a migration file in insurance/migrations/ based on differences between entities and database.
Run migrations:
npm run typeorm:migrate:runRevert last migration:
npm run typeorm:migrate:revertShow migration status:
npm run typeorm:migrate:showRun all pending migrations:
npm run typeorm:migrate:runFor development (both Prisma and TypeORM):
npm run db:migrate:devFor production deployment:
npm run db:migrate-
Update schema files:
- Prisma: Edit
prisma/schema.prisma - TypeORM: Edit entity files in
insurance/entities/
- Prisma: Edit
-
Generate migrations:
npm run prisma:migrate:generate -- describe_change npm run typeorm:migrate:generate -- -n DescribeChange
-
Review generated SQL:
- Check
prisma/migrations/[timestamp]_describe_change/migration.sql - Check
insurance/migrations/[timestamp]-DescribeChange.ts
- Check
-
Test locally:
npm run db:migrate:dev
-
Commit migration files:
git add prisma/migrations/ insurance/migrations/ git commit -m "feat: add database migration for feature X" -
Deploy to production:
npm run db:migrate
- Always review migrations before applying - Especially in production
- Never edit migration files after they've been applied
- Test migrations on a staging database before production
- Backup database before running production migrations
- Use descriptive names for migrations (e.g.,
add_user_email, notupdate) - One logical change per migration - Don't bundle unrelated changes
- Test rollbacks - Ensure
typeorm:migrate:revertworks correctly - Monitor migration logs - Watch for errors or warnings
When multiple developers create migrations:
- Pull latest changes
- Run existing migrations:
npm run db:migrate:dev - Generate your migration
- Test the complete migration chain
- Commit and push
If a migration causes issues:
TypeORM:
npm run typeorm:migrate:revertPrisma: Prisma doesn't support automatic rollback. You must:
- Manually write a reverse migration SQL
- Apply it using
prisma db execute - Or restore from backup
- NEVER use
prisma db pushin production - it doesn't create migration files - NEVER set
synchronize: truein TypeORM for production - it can drop columns - ALWAYS commit migration files to version control
- ALWAYS test migrations with production-like data volumes
- TypeORM migrations run in transactions by default
- Prisma migrations are atomic
- Database should rollback automatically
- Check logs for specific error
- Migration history is out of sync
- Run
prisma migrate resolve --applied [migration_name]for Prisma - Check
typeorm_migrationstable for TypeORM
- Generate new migration to sync:
npm run typeorm:migrate:generate - Or reset database (dev only):
npm run prisma:migrate:reset
Required for migrations:
DATABASE_URL=postgresql://user:password@localhost:5432/stellar_insuredFor production, ensure:
- Database user has ALTER TABLE permissions
- Connection pool is configured correctly
- SSL is enabled if required