I want to find commands for a development flow where i can • Locally indev: push the current state of the schema to the generator and database (test database as in my local .env) • When committing: Save all changes since the last schema commit as a migration, to cleanly apply the changes on the production server • When pulling on server: Apply the new migrations I thought i already had commands for 1) and 2) 1 being

prisma db push

2 being

prisma migrate dev

but this doesnt seem to be the case: when running 2 locally, it warns me that database drift has been detected, and it will have to reset my database Can someone help with this? What is the correct way of doing this?

Hey @Temm! The

prisma db push

will only apply the migration history to your database, and the

prisma migrate dev

will do it , and create a new migration. So I believe that what you need to do is run

prisma migrate dev

locally, to generate the new migration. When pulling from the server you can use the

prisma db push

to apply the current schema to the database, without creating a new migration, that has to be sync.

@Daniel Olavio Ferreira hey there!

prisma db push

i've been using prisma db push to sync the database with the schema without creating a migration (because that is what it does - at least thats the effect i observed) This will of course sync the database with the schema, but desync it with the migration history. I am definetly unable to manually create the migrations - i chose prisma because i want to avoid writing SQL as much as possible. Isnt there a command that creates a migration from the last state of the migration history to the current state of the database/schema?

@Temm What you could do that would help is running a Prisma instrospect, to update your schema based on your database, then run a Prisma migrate to generate the migration. I would do this in a separate branch, since it's going to delete your current schema file and create a new one, so some relation names might change. Give it a try and let me know how it goes. But it might do what you want. Just keep in mind always create migrations when deploying changes, because this method that I talked about is a workaround and not recommend for day to day use.

@Daniel Olavio Ferreira Running

prisma migrate

didnt do any changes aside from reordering things and adding

@@index

to models. This was what i expected - my test database was already in sync with my schema, just my migration history was catching behind because i pushed the schema to the database via

prisma db push

instead of

prisma migrate dev

. My question was, how i can generate the migration files to bridge the gap between the current migration state and the current schema state - i dont want to do any operations on the database, as it is already in sync with my prisma schema. Isnt there a command to just do exactly that? I used

prisma db push

to avoid spamming migrations when making tiny testing changes in my dev envoirement - i dont want to create a hundred tiny unnessecary migrations for that.

Uhhmm, you could try

prisma migrate dev --create-only

I believe this would work then. Just double check that this is the correct syntax for the command. This should only generate the migrations without trying to sync with your database

@Daniel Olavio Ferreira Sadly this also seems detected database drift between my schema and my migration history, and is prompting to reset the database

So probably the introspection method that I told you earlier would be the way to go. That would assure that your schema is up-to-date with your db and them you would be able to create new migrations

@Daniel Olavio Ferreira I've tried running introspect first - introspect only seems to pull the current state of the database schema to the prisma.schema though. Those two are already in sync for me - only the migration history is out of sync - so introspect doesnt do anything (or at least nothing useful - rearranges stuff and adds

@@index

) So i dont think that this is what i want either

Uhhmm what you could maybe do is delete your migration history both in Prisma and in your db and start the migrations from scratch, I don't know any other way for this type of situation. @Ryan anything else you think that could be done?

migration history is empty: Issue occours.

There’s one option that you can perform on your development database but that would mean resetting your data: 1. Use

prisma db push

to prototype and make any changes you want. 2. Run

prisma migrate dev

and apply migrations (this will reset your data)

@Ryan Yes, that is literally exactly what i was initially intending to do until i found out that step 2) will reset the database - which shouldnt be nessecary by my understanding? Is this intended+nessecary or should i make an issue about this?

This is the intended behaviour and only applies to development databases.

@Ryan Alright, thanks for the answer. I ended up sacrificing my test db data and cloning it again from the live database to create the migration. I may have fucked up a bit now though - i had previously missused the commands, and used

prisma db push

on the live server, instead of having created a migration indev and then applying that on the server. This means that im now unable to apply the migration on my live server, as doing so would require a database reset, even though the prisma schema and the database schema are already in sync, simply because i had missused the commands and not created a migration. What is the way out of this? Forcing the developer to reset the database to create a migration even though the prisma schema and the database schema are already in sync seems a bit arbitrary - could this not be removed, is it really a hard requirement? I know that i made quite a mistake by not using migrations, but this is my current situation.

You can baseline your production database as explained here. In this case, you need to have migrations created from your dev environment (which can be reset) and run

prisma migrate resolve

for the migrations to the production environment.