Skip to main content
PC Fix uses Prisma as its ORM and Prisma Migrate for managing database schema changes. This guide covers creating, applying, and managing migrations throughout the development lifecycle.

Overview

Prisma Migrate enables version-controlled, type-safe database schema management. All schema changes are defined in packages/api/prisma/schema.prisma and tracked as migration files.
Migrations are stored in packages/api/prisma/migrations/ and should be committed to version control.

Prisma Schema

The schema defines your database structure using Prisma’s DSL:
schema.prisma
The full schema is located at packages/api/prisma/schema.prisma and contains 20+ models including User, Producto, Venta, Cart, and more.

Common Migration Workflows

Creating a New Migration

When you modify schema.prisma, create a migration:
1

Edit Schema

Modify packages/api/prisma/schema.prisma:
2

Create Migration

Generate migration files:
This will:
  • Generate SQL migration file
  • Apply migration to database
  • Regenerate Prisma Client with new types
3

Review Migration

Check the generated SQL in prisma/migrations/TIMESTAMP_add-product-discount/migration.sql:
4

Commit Changes

Applying Existing Migrations

When pulling changes from git or deploying:
Applies pending migrations and regenerates Prisma Client.

Resetting the Database

This will delete all data! Only use in development.
This will:
  1. Drop the database
  2. Create a new database
  3. Apply all migrations
  4. Run seed script (if configured)

Prisma Client Generation

After schema changes, regenerate the Prisma Client:
This updates TypeScript types to match your schema. Run after pulling schema changes from git.

Database Seeding

PC Fix includes a seed script for populating test data:
prisma/seed.ts
Run the seed:
Seeding is configured in packages/api/package.json:

Prisma Studio

Explore and edit database records with Prisma Studio:
Access at http://localhost:5555
For Docker: docker exec -it pcfix-api npx prisma studio

Common Prisma Commands

Migration Best Practices

1

Test Locally First

Always test migrations on local database before deploying:
2

Use Descriptive Names

Name migrations clearly:
3

Review Generated SQL

Check migration files before committing:
4

Backup Production Data

Before running migrations in production:

Handling Complex Migrations

Data Migrations

For migrations that require data transformation, edit the generated SQL:
migration.sql

Breaking Changes

For breaking schema changes:
  1. Deploy in stages:
    • Add new fields (optional)
    • Update application code to use new fields
    • Make fields required
    • Remove old fields
  2. Use database transactions:
  3. Plan rollback strategy:

Troubleshooting

If a migration fails:

CI/CD Integration

Add migration checks to your CI pipeline:
.github/workflows/ci.yml

Next Steps

Database Schema

Explore the complete database schema

Backend Architecture

Learn about the API structure

Environment Setup

Configure database connection

Testing

Test database operations