Hey guys, I have a huge table in dev db with a script to seed it but it takes 1hour to run. I wanted to know how would you resolve schema drift in my case ? For example if another branch change the db schema I can’t run others migrations because of the schema drift (I’ve seen in the doc that it resolve this by reset the database but in my case I have to wait 1 hour to seed it)

Hi @Theo Letouze 👋 Schema drift occurs in the development environment if you made manual changes to the database without migrations and you would need to introspect it if you want to keep the changes.

But imagine I’m on a branch “b” and a colleague is on a branch “a”, my colleague does a migration (on branch “a”) to add a field to the user’s table. Few minutes after I want to create a new migration on my branch (branch “b”). I’ll have an error because the migration table in the database has a new line with my colleague’s migration which is not in my migration folder. So I can’t make a new migration

what you're experiencing is a migration history conflict as documented here

If Prisma Migrate detects a migration history conflict when you run prisma migrate dev, the CLI will ask to reset the database and reapply the migration history.

But it’s diffucult for me to reset my database because I have a script to seed my db with initial data which take 1 hour to be executed

I'm curious to understand why the seed script takes that long.

because there are a lot of data

Do you really need all 17 million rows of data in dev/staging environment? Is it possible to select a subset of that data?

it’s for AI functions so I think so

I actually do think

prisma migrate diff

can be of help here since you can

migrate diff

your migration history directory with the current database schema to know what further changes are necessary to bring your database schema to your desired state.

Hi, I don’t know yet, for now we work on the same branch but I was thinking about another case where we are not on the same branch

Hi @Theo Letouze, You should be able to update your schema and apply migrations on it. Take a look at this example from the docs.

thank you it’s very interesting. But I don’t see where he updates his datamodel from the db in this example ?

Hi @Theo Letouze, I don't believe Raphael was able to see your message before he ended his work day and he's on leave today for a national holiday. I'll raise this with the team and we'll try to get back to you asap! 🙂

@Vladi Stevanovic ok ! Thank you a lot

Hi @Theo Letouze, If you update from the db, you would need to introspect the changes so that it can reflect in your Prisma Schema.

Ok si I need to do prisma db pull + prisma migrate diff between database and migrations file but what can I do with this sql because I have to create a migration file to match the migrations name in the db right ?

Hi @Theo Letouze, I'm not sure i understand your last statement. Can you please rephrase?

Because my migration folder and my data model mismatch with the state in the database so I need to prisma db pull to update my datamodel but how can I update my migration folder ? If I use prisma diff it will generate the missing sql lines, what can I do with these

You would take the sql, and pass it to

prisma db execute

command.

I’ve already read this but db exécute will update the database not my migrations files

Hey Theo, chiming in here

But imagine I’m on a branch “b” and a colleague is on a branch “a”, my colleague does a migration (on branch “a”) to add a field to the user’s table. Few minutes after I want to create a new migration on my branch (branch “b”). I’ll have an error because the migration table in the database has a new line with my colleague’s migration which is not in my migration folder. So I can’t make a new migration

Based on this, I have a follow-up question: • Are you sharing the same database between both branches? Generally, I recommend using a separate table when working in different environments, i.e., staging, prod, and locally. If you’re working with PostgreSQL and Netlify/ Vercel, Snaplet is working on a Preview Database plugin. This could serve as inspiration when isolating databases in different environments. One way to think about Prisma Migrate regarding schema drifts is that it’s a state management tool for database schemas. (If you’re sharing the same database): In the scenario you shared, if I understand correctly, your colleague updated the database by adding a field, your “branch.” In this case, your Prisma schema and database migrations are one step behind your colleagues. Your colleague’s migration was already marked as applied by Prisma Migrate when they made the change. To fix this, you could merge your colleague’s branch into yours. This would update your version of the Prisma schema and migration history—

/prisma/migrations

. You could then confirm it’s resolved by running

prisma migrate deploy

. (If you’re working on separate branches and separate databases) You can resolve the conflict by merging your colleague’s branch into yours — it would contain the updated Prisma schema migration history. You can then run

prisma migrate deploy

or

prisma migrate dev

to apply any pending changes to your development database. You will then be able to continue making schema changes to your database after this. Let me know if this answers your question @Theo Letouze. 🙂

Hi! Thank you for the answer! We are using the same database and I understood your solution but what about if I don’t want to merge all his new files? I could use git checkout <path> to get only the migrations files and his prisma schema as explained there https://jasonrudolph.com/blog/2009/02/25/git-tip-how-to-merge-specific-files-from-another-branch/ Are you agree with my point?

I agree with you. Merging the Prisma schema and

./prisma/migrations

directory from your co-worker’s branch might be a more elegant solution for your case. The migration workflow might be a little more complex, but that should do it. Follow-up question, if you don’t mind, is there a particular reason you’re sharing the development database? I’d like to learn more about your use case 🙂

I only have dev/preprod and prod databases which are deployed on ovh cloud so everybody in the company are using the same dev database but I agree it could be a better solution to have a local database for each developers