Custom Migrations
What's the recommended way to customize migrations that aren't supported by Prisma Schema directly?
More specifically, if I wanted to add Partial Indexes, Collations, Computed fields, etc..., I recognize we'd likely need to update the generated migration file. That ends up defeating the purpose of Prisma Schema (a snapshot of your DB schema) as there is info not represented.
Are comments the only solution here or is there some (undocumented) way to develop custom annotations that affect the migration?
6 Replies
Skipping coffee for instant knowledge! Let's brew that AI answer now.
Context: Looking for a way to avoid using something like https://atlasgo.io/guides/orms/prisma/postgresql-partial-indexes to manage these custom things because I don't want to pay for Atlas to use composite schemas š
To customize migrations for features not directly supported by Prisma Schema, such as partial indexes, collations, and computed fields, the recommended approach is to use custom SQL in your migration files. Here's how you can do it:
1. Generate a migration without applying it:
2. Open the generated migration file and add your custom SQL for unsupported features.
3. Apply the modified migration:
This process is documented in Prisma's guide on unsupported database features.
However, you're correct that this approach has limitations:
1. The Prisma schema won't fully represent your database schema, as it can't capture these custom features.
2. Prisma may try to drop custom indexes or alter custom fields in subsequent migrations.
Currently, there's no built-in way to develop custom annotations that affect migrations. The closest solution is to use comments in your Prisma schema to document these custom features, but these comments won't affect the migration process.
Some users have requested features to address this issue:
1. A way to ignore indexes on Prisma Schema
2. Support for partial unique indexes
These feature requests highlight the need for better support of custom database features in Prisma.
For now, the most reliable approach is to carefully review and potentially modify each generated migration before applying it, especially if you've added custom features to your database. This ensures that Prisma doesn't inadvertently remove or alter your custom additions.
š¤ Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly.
In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.
Hey Sabin š
Are comments the only solution here or is there some (undocumented) way to develop custom annotations that affect the migration?There isn't any undocumented way I am aware of. For now, the suggested solution is only this one: Unspported database features Though you are correct, that these features would not be represented in the Prisma Schema file.
Prisma Migrate: Unsupported database features | Prisma Documentation
How to include unsupported database features for projects that use Prisma Migrate.
Gotcha, thanks for the response! This ends up being a bit limiting for some common use-cases. Is there something on the roadmap for this?
I don't think so, the team is currently focused on the Query Compiler Initiative - moving from rust to TS, which should considerably improve performance. Besides that, every quarter we are working on top 5 highly requested features. You can expect a similar roadmap soon: https://github.com/prisma/prisma/issues/25794
GitHub
Prisma ORM Roadmap: Dec 2024 - Feb 2025 Ā· Issue #25794 Ā· prisma/pri...
3 Month Roadmap: Dec, Jan, Feb 1. Maintain a Healthy and Manageable Backlog of Open PRs and Issues Goal: Ensure any one developer can maintain a clear overview of all open PRs and issues. Right now...