Hey all, we recently ran into an issue with migration ordering and was wondering if theres any way we can avoid this going forward. Problem described below: Problem: PR 1 had a migration named 20220110_foo_bar PR 2 had a migration named 20220115_foo_baz We accidentally merged in PR 2 first and ran the migration in prod. Prisma or git didn’t complain (but we wish it did). PR 1 was merged afterwards and ran in prod. The nature of the migration didn’t directly impact the migration in PR 2 so we were ok but now our migrations are out of sync/complaining when developing locally. We can manually fix the issue by removing the entry in

_prisma_migrations

and commenting out the SQL in PR 1 but this is a hack and we are lucky. Question: Can prisma migrations be numbered sequentially? Or, is there a migration state file we can generate and check in to our codebase? Very similar to how Django handles migrations. I feel like this is a pretty obvious drawback and am wondering if anyone else has faced this issue. Thanks in advance!

👀

They should be ran sequentially in the future by date? or does it run by the record they ran if so that seems very wrong (that's why we have the date stamp at the start)

I think they should be generated and run sequentially OR there should be a “migration state” file that can be checked in. That way git will complain about a conflict

most migrations run sequentially date+timestamp

correct but there is a flaw based on my example above

there's a lot resolving around with that flow though regardless of state if you add keys or something to the db and it already has records etc