Quick question. I have a migration that has been in a branch for a long time. Since then we reset our migrations and the original

init

and all other migrations now have a later dated migration folder name. It seems to have deployed ok in our staging environment, but locally it causes issues. I am thinking about changing the name of the migration folder to a later date, and then manually updating the

_prisma_migration.migration_name

to the new name in the database. Does anyone see any glaring issues with that? Thanks!

@Cole Voss 👋 I think this should work but I’ll let @janpio clarify.

That would probably work, but maybe there is a better automated way

@tom can probably help with this - I think technically this is possible. Would be nice to see as well if there’s any learning for us here that we could eventually apply to the product surface.

I would be interested in knowing the errors you are seeing locally. In case you want to move the migration later in history, the way I would do this without needing to fiddle with the migrations table manually is first do it locally, test that the new migration order works (

migrate dev

will do that), and then use

migrate resolve --applied <the-new-migration-name>

on your production database — this will mark the migration as already applied with its new name in the migrations table, and next time you

deploy

it won't be run.

Oh. That is awesome feedback. I was able to get it resolved by doing what I described above manually (and very carefully). The migration ran just fine against that environment, but locally we run things in containers and the database is started and all migrations run on app start up. With our current deployment pipeline, I’m not sure how I would have ran the

migrate resolve …

since our whole pipeline is automated and runs migrations on start up. I would either have to proxy to my DB and mock our dev env to be like our stage/prod environment and then run it locally against that, or introduce some sort of one off script to run on a deployment and then remove it immediately. That said, I will look further into the

resolve

CLI to see if I can leverage it in the future.