Implement Display of Destructive Changes

[mavilein]

The migration engine has now implemented support for checking for destructive changes. The output of applyMigration can now return a non empty array in the warnings property. If that is the case the CLI must send the force parameter as true so the user acknowledges the destructive change.

The JSON for warnings looks like this:

[
  {"description": "You are about to drop the table `User`, which is not empty (11 rows)."},
  {"description": "You are about to drop the column `name` on the `User` table, which still contains 23 non-null values."}
]

Note: The migration engine currently ignores the force flag and applies the migration even if there are destructive changes. This is temporary until the CLI has implemented support for this and we can enable the proper behavior.

[mavilein]

I have created a specs issue about this topic.

[matthewmueller]

@mavilein do we receive enough information here to also show a diff?

[mavilein]

@matthewmueller : No. Currently it is just a plain String describing the data loss. What kind of diff would you like to show?

[matthewmueller]

Thanks, I'll formalize this more, but quick stream of thoughts on what I'd propose:

Delete a model:

- model User {
-  id Int @id
-  firstName String
-  lastName String
-  @unique([firstName, lastName], name: "fullName")
- }

Rename a field + update an attribute:

model User {
   id Int @id
-  firstName String
+  givenName String
   lastName String
~  @unique([givenName, lastName], name: "fullName")
}

We may have this information already on the client, but if not, it probably makes sense to send it

[mavilein]

@matthewmueller : How are your proposals related to destructive changes? I think we have this kind of data model diffing in the CLI already. A deleted field might not lead to data loss at all hence i don't see how this moves this forward.

[matthewmueller]

The spec is not describing the --force flag or a replacement that we had in P1. To my understanding we definitely need that.

I originally had a confirmation dialog with an --auto-approve dialog during lift up. I removed that flow after I learned that lift up doesn't seem to use it.

We should think about when we want to display destructive changes. Shouldn’t we maybe show already in lift save? It would be annoying to run lift save and later find out that the migration is actually destructive when running lift up.

How are these messages obtained? It feels like it would be slow to learn some of this and halting the developer flow to save a migration seems iffy.

[mavilein]

@matthewmueller : What do you mean with How are these messages obtained??

[matthewmueller]

@mavilein for example:

"You are about to drop the column name on the User table, which still contains 23 non-null values."

I'm assuming this would do something like:

select count(name) from User where name is not null

If that's the case, could that get really slow on large datasets? And if you're making sweeping changes, it could require N queries for N changes.

I'm trying to get a gauge of how slow this could be when I type lift save, since you don't expect saving a migration locally to be slow.

[mavilein]

@matthewmueller : Yes this is what we do. I think this is a valid concern. We have not had problems with this approach in Prisma 1 though.