Prisma migrate - always reporting Data loss / migration file changed even with simple field addition

Say I have a scheme (you already have a copy of my schema for https://github.com/prisma/prisma/issues/4748).

Adding a simple field like status Int @default(0) then running migrate. It reports:

I can assure you those migration files have not been manually changed since they were applied. This happens without fail for me.

There is no way for me to be able think about using this in production (or even alpha testing) with simple fields being added causing a DB reset.

How to reproduce

Have a scheme (use my example one if needs be as this is the one I’ve used) and without making any changes, run:

1: npx prisma migrate dev --create-only --preview-feature 2: npx prisma migrate dev --preview-feature

Let it apply the migrations, then add the status field as above to the model Arc in my schema. Then run the above commands again. It will complain with the error in the screenshot.

Environment & setup

• OS: Windows
• Database: MySQL 8.0
• Node.js version: 12
• Prisma version:

@prisma/cli          : 2.14.0
@prisma/client       : 2.14.0
Current platform     : windows
Query Engine         : query-engine 5d491261d382a2a5ffdc71de17072b0e409f1cc1 (at ..\..\..\..\node_modules\@prisma\engines\query-engine-windows.exe)
Migration Engine     : migration-engine-cli 5d491261d382a2a5ffdc71de17072b0e409f1cc1 (at ..\..\..\..\node_modules\@prisma\engines\migration-engine-windows.exe)
Introspection Engine : introspection-core 5d491261d382a2a5ffdc71de17072b0e409f1cc1 (at ..\..\..\..\node_modules\@prisma\engines\introspection-engine-windows.exe)
Format Binary        : prisma-fmt 5d491261d382a2a5ffdc71de17072b0e409f1cc1 (at ..\..\..\..\node_modules\@prisma\engines\prisma-fmt-windows.exe)
Studio               : 0.332.0

[webnoob]

Ok - good to know. It’s not holding up my workflow at the moment so I’ll stay on latest so I can easily test for you guys. Just hit me up when you need some info! 😃

p.s Appreciate all your work 🎉

[webnoob]

This issue seems to have been resolved in 2.18.0. I added one prop against my Book model and the generated SQL was:

-- AlterTable
ALTER TABLE `book` ADD COLUMN     `randomField` VARCHAR(191);

No foreign keys being dropped or recreated and no data loss warnings (as I would expect with a simple change like this) 🥳

Thanks for your hard work @tomhoule and @Jolg42

Update 2.18.0 - the one update to rule them all!