Executing data migration/data field seed script for a migration automatically
I did a quick search on the topic but didn't find any concrete solution I can use and it is quite the everyday case. Basically, I need to introduce a new required field in my db (postgres). The recommended solution is the expand-contract pattern where I first introduce the field as optional, then seed the data and then make it required in 2 separate migrations. For the data seeding aspect, I see a couple of options: default value in schema (which can reduce the migrations to 1), modify the migration
.sql to seed the field or execute a script manually after the migration before proceeding. However, none of the solutions for seeding cover my case. I need to be able to execute a sequence of migrations without going 1 by 1 and manually running data migrations scripts inbetween. Basically, I want to create the field, seed the data and make it required in one migrate deploy step. How can I achieve that? Can I somehow associate a data migration script to every migration that gets executed automatically before the next migration or something? I can't use @default() as the data is calculated dynamically.5 Replies
The only viable solution I see currently is to store my data migration/seed script in the migration folder and instead of running the general
migrate dev/deploy to introduce a custom migration handler that iterates over the migration files, checks which of them are not yet applied and running each of them separately by executing migrate dev/deploy --to <current-migration> and the checking if there is a data migration script to execute before proceeding to the next migration. This, however, seems quite overwhelming for something so ordinary.Hello 👋
Basically, I want to create the field, seed the data and make it required in oneWouldn't customizing your migration file work for your use case? You can create a migration file without applying it with
--create-only flag:
https://www.prisma.io/docs/orm/prisma-migrate/workflows/unsupported-database-features#customize-a-migration-to-include-an-unsupported-feature
Then you can edit the migration file to seed the data (with raw SQL) and as a last step make the field as required. All in one migration.Prisma Migrate: Unsupported database features | Prisma Documentation
How to include unsupported database features for projects that use Prisma Migrate.
Thank you for the input. The thing is, the logic to seed the data is complex and can't be handled inside the sql, at least in this case.
Ah, okay!
We have a related feature request here related to your use case:
https://github.com/prisma/prisma/issues/19513
Can you add a 👍 to the request? It helps us in prioritising requests
GitHub
Adding JS execution before and after migrations to allow for easier...
I love Prisma, but an issue that has been mentionend many times in the main repo (0, 1, 2) is how hard it is to create data migrations. Sure, you could write them in raw SQL, but writing logic-heav...
Thank you, will do.
Meanwhile, can you advice on a solution that circumvents this problem?