Prisma1: prisma deploy --force flag seems to have no effect

[carstenbaumhoegger]

Bug Report

I'm currently bootstrapping a new GraphQL server using Prisma. While developing I have breaking changes that need to be deployed, the existing data can be overwritten.

Current behavior
I use prisma deploy -f to force prisma to deploy the changes even if there are data changes as described here

This produces the exact same amount as if i would have used prisma deploy without flags. I have to remove my existing service and re-deploy it.

Reproduction
Make a breaking change to your datamodel.graphql that leads to errors when using prisma deploy. Then used prisma deploy -f to force the changes.

Expected behavior?
prisma deploy -f just overwrites the existing service regardless of the breaking changes

[marktani]

Can you clarify which change exactly exhibits this behaviour? Ideally with a "before" and "after" schema 🙂

[carstenbaumhoegger]

Sure!

initial datamodel:

type User {
  id: ID! @unique
  firstname: String!
  lastname: String!
  createdAt: DateTime!
  updatedAt: DateTime!
}

Then I insert a user e.g.

mutation {
  createUser(data: {
    firstname: "Test", 
    lastname: "User"}
) {
    id
  }
}

now I want my user to have a gender which is required.
modified datamodel:

type User {
  id: ID! @unique
  firstname: String!
  lastname: String!
  gender: Gender!
  createdAt: DateTime!
  updatedAt: DateTime!
}

type Gender {
  id: ID! @unique
  gender: String!
  createdAt: DateTime!
  updatedAt: DateTime!
}

If I run prisma deploy now it displays

Deploying service `default` to stage `default` to server `local` 21ms

Errors:

  User
    ✖ You are creating a required relation, but there are already nodes that would violate that constraint.

I expected this output and use prisma deploy -f to just override my existing user. The result is the same as shown above, the deployment fails.

Am I misunderstanding the purpose of --force?

[marktani]

Ah ok, that's interesting!

I think it is justified that --force doesn't work in this situation, because here it would lead to an _inconsistent_ schema - after the deployment, the service schema + data wouldn't be valid because a user with null as Gender exists.

I already suggested an improvement for adding required fields to the schema with existing data here: #2323 🙂

I'll leave this issue open, as we certainly should improve the error message:

If a deployment would result in an _inconsistent_ schema, we should not recommend to use --force.

[carstenbaumhoegger]

Alright, changing the error message sounds like a good idea to avoid misunderstanding.

What would be the best solution for my use case when bootstrapping the server and doing inconsistent changes to the schema?

Just deleting the service and re-deploy?

[marktani]

Yep, or migrate existing data to be conformant with the constraints that you are about to introduce.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AviIhej]

Still getting this issue. Has anyone solved it?

Warning:
User
! You already have nodes for this model. This change will result in data loss.

[mikeislearning]

Ya, this definitely needs to be resolved. Maybe add a data-loss flag? I imagine there are a lot of people who don't care about losing data if they're doing a force deploy

[brainafesoh]

Yep, or migrate existing data to be conformant with the constraints that you are about to introduce.

Hi how could this be done properly? with a script or with manual mutations?

[cromieent]

As I'm just in development, I really don't care about the constraints right now. I realize that a field needs to be introduced, and it has to be required.....so I have to lose all my test data to put the new field in? I suppose I can introduce it as not required, then populate the data, then require it...

[josh-mercarto]

If you're using prisma with docker. You can always just delete the volumes which will destroy your database.
E.g. docker-compose down -v.
Then running prisma deploy should generate the new schema for you without any errors.