🏗️ Factorwise Project — Prisma Schema

Welcome to the Factorwise Project Schema Repository.
This repository contains the official Prisma schema, migrations, and related setup for the Factorwise backend system. It is designed specifically for Factorwise and must not be reused or modified for any other projects.

⚠️ Important:
This is a private schema. Usage of this schema outside of the Factorwise environment is strictly prohibited.

📚 Table of Contents

• 📌 Project Overview
• 🛠️ Tech Stack
• 📂 Project Structure
• 🚀 Getting Started
• 🧭 Development Workflow
• ⚡ Common Commands
• 🔒 Important Notes
• 📄 License

📌 Project Overview

This schema serves as the single source of truth for the Factorwise backend database.
It defines the models, relations, enums, and constraints required for all services interacting with the Factorwise data layer.

• ✅ Centralized schema for all DB models
• ✅ Managed migrations with Prisma
• ✅ Enums and mappings aligned with business logic
• ✅ Designed for multi-tenant setups using Prisma Client

🛠️ Tech Stack

• Prisma ORM — Database modeling & migrations
• TypeScript — Type-safe schema and client code
• MySQL — Primary database engine
• Node.js / NestJS — For backend integration

📂 Project Structure

• prisma/schema.prisma → Core database models and enums for Factorwise.
• migrations/ → Auto-generated by Prisma when pushing changes.
• package.json → Used for managing versioning and publishing the schema internally.
• README.md → Project documentation.

🚀 Getting Started

npm install


npx prisma generate


npm run db:plan -- describe_your_change

Production database changes

Do not run prisma db push against production. This database is large and has historical schema drift, so db push can unexpectedly alter unrelated tables.

Use one focused, reviewed SQL change instead:

1. Commit the current schema as the baseline.

2. Edit prisma/schema.prisma with one logical change.

3. Generate SQL containing only that edit:

   npm run db:plan -- add_customer_key

4. Review the generated file in prisma/changes/. The command reports common operations that scan, lock, or rebuild populated tables.

5. Test the SQL on a production-sized staging database. For an index or foreign key on a large table, use an online schema-change tool and schedule it during low traffic; Prisma cannot make the MySQL table operation instant.

6. Apply the exact reviewed file:

   npm run db:check -- prisma/changes/<file>.sql
   npm run db:apply -- prisma/changes/<file>.sql
   npm run generate

   The command asks you to type APPLY before connecting to the configured database. A file containing DROP TABLE or DROP COLUMN asks for a second DELETE confirmation. Non-interactive CI can use --confirm-production and, for destructive changes, --confirm-data-loss.

7. Commit schema.prisma and the SQL change file together.

db:plan compares the working schema to the committed schema rather than the live database. This prevents old, unrelated database drift from being included in a new production change. The db:apply command uses the database configured by DATABASE_URL; verify that target before confirming production execution.

Built and maintained with ❤️ by the Factorwise Development Team.