actually, it looks like they aren’t, just for some reason my attempted forced failure of dropping a primary key column was ignored. and it looks like follow up migrations, if marked as resolved, result in secret “partial migration successes”? (aka the commands after my failed command in the migration that had to be rolled back) i’m inclined to just tell my team to wrap all their migration files in BEGIN/COMMIT, as suggested in the issue, but I am curious what the intended behavior here is. I guess it’s just that nobody ever has a partially failed migration? Or is there some other resolution pattern? 😕

i see now the recommended path is to introspect the live database and generate a supplementary sql file: https://www.prisma.io/docs/guides/database/production-troubleshooting#moving-forwards-and-applying-missing-changes. . I am curious if others have thoughts about this approach, or if they are successfully just using BEGIN/COMMIT instead. This seems like a tedious step involving potential live database introspection that does not seem like an ideal default, but i could totally be looking at it wrong 😅

more specifically asking a question - is there anyone happily using the method of manually ensuring your migration files are wrapped in BEGIN/COMMIT? This seems more stable to me in that it provides a safe rollback state for both the client+app and database. But I’d hate to pursue it too far if i’m just thinking about the suggested approach of

prisma db execute

too critically. 🙇