* feat: Cal.diy — community-driven MIT-licensed fork of Cal.com This squashed commit contains all Cal.diy changes applied on top of calcom/cal.com main: - Rebrand Cal.com to Cal.diy across the entire codebase - Remove Enterprise Edition (EE) features, license checks, and AGPL restrictions - Switch license from AGPL-3.0 to MIT - Remove docs/ directory (migrated to Nextra at cal.diy) - Remove dead code: org tests, EE tips, platform nav, premium username, SAML/SSO, etc. - Clean up .env.example for self-hosted Cal.diy - Update Docker image references to calcom/cal.diy - Update README, CONTRIBUTING.md, and issue templates for Cal.diy community fork - Add PR welcome bot for Cal.diy contributors - Fix API v2 breaking changes oasdiff ignore entries - Replace Blacksmith CI runners with default GitHub Actions 3893 files changed, 20789 insertions(+), 411020 deletions(-) Co-Authored-By: benny@cal.com <sldisek783@gmail.com> * refactor: remove org-specific /organizations/:orgId endpoints from API v2 atoms controllers (#1701) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * fix: revert Cal.diy Inc to Cal.com, Inc. in license files, copyright notices, and package metadata (#1702) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> * rip out org related comments in api v2 --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
53 lines
1.7 KiB
Markdown
53 lines
1.7 KiB
Markdown
---
|
|
title: Prisma Schema and Migrations
|
|
impact: HIGH
|
|
impactDescription: Schema changes affect all downstream code and deployments
|
|
tags: prisma, database, migrations, schema
|
|
---
|
|
|
|
# Prisma Schema and Migrations
|
|
|
|
## After Schema Changes
|
|
|
|
After making changes to the Prisma schema in Cal.diy and creating migrations, you need to run:
|
|
|
|
```bash
|
|
yarn prisma generate
|
|
```
|
|
|
|
This updates the TypeScript types. This is especially important:
|
|
- When switching Node.js versions
|
|
- After adding new fields to models
|
|
- After pulling changes that include Prisma schema updates
|
|
|
|
## Creating Migrations
|
|
|
|
```bash
|
|
# Development migration
|
|
npx prisma migrate dev --name migration_name
|
|
|
|
# Production deployment
|
|
yarn workspace @calcom/prisma db-deploy
|
|
```
|
|
|
|
## Timestamp Fields
|
|
|
|
When adding timestamp fields like `createdAt` and `updatedAt`:
|
|
- Do not set default values if you want existing records to have null values
|
|
- Only new records should get timestamps automatically
|
|
- For `updatedAt` fields, ensure they're updated when records are modified
|
|
|
|
## Squash Migrations
|
|
|
|
Whenever you change the schema.prisma file, remember to always consolidate migrations by squashing them as declared in the [Prisma docs](https://www.prisma.io/docs/orm/prisma-migrate/workflows/squashing-migrations).
|
|
|
|
This helps maintain a clean migration history and prevents accumulation of multiple migration files.
|
|
|
|
## Enum Generator Errors
|
|
|
|
If you encounter enum generator errors during the Prisma generate step (like "Cannot find module './enum-generator.ts'"), run `yarn install` first before trying to generate.
|
|
|
|
## Cache-Related Features
|
|
|
|
When implementing cache-related features that require timestamp tracking, always update the database schema first before modifying application code that references those fields.
|