set the channel topic: https://github.com/prismagraphql/prisma/issues/1263

Not gonna post this on github as this is mostly a +1 comment but it really seems painful to rename a table with a temporary directive. I'm just building a small demo app for a talk and even I immediately recognized the pain that is described in this comment: https://github.com/prismagraphql/prisma/issues/1263#issuecomment-390849825

The core problem with temporary directives is there is no history of how the db got from point A to point B. This becomes a nightmare when trying to deploy code. The code base should be entirely stateless from environment.

Here’s an example: Developer A publishes a feature to production Developer B pulls Developer A’s branch and renames property X to Y, while creating property Z Developer B removes the temporary directive from property Y (formerly X) and renames property Z to W with another temporary directive. Developer B deploys this code to production. 2 things break: 1. Production won’t be able to rename Z to W, because according to the existing prod database, Z doesn’t exist yet. 2. Production will interpret the X to Y change as removing a field and adding a field, because it has no record of the temporary directive (It was added after Prod’s codeset, but before Developer B merged his code back in)

The way I see it, we want to heartily avoid re-writing Git, or having any kind of source control dependency

And stacking rename directives on top of rename directives sounds really awful

Writing migrations by hand may be a useful feature to have, but being forced to would instantly kill 50% of Prisma’s value.

Keeping some sort of automatically generated log would be awesome 😎

Alternatively, instead of adding temporary directives to schema, if we could add a line to some sort of migration file, that could work. Then if we could have the option of adding separate migration mutations to that migration file, then we’d be set. Explicit changes could be inferred, and ambiguous or very intentional migrations could be handled in an organized fashion.

Hey! I understand that there is a deep discussion about how to implement migrations into Prisma, but I couldn’t find any recommendations for performing complex migrations at the time being. My hunch is that I could disable Prisma migrations in config, then change the db schema and update values on my own (for example, using https://github.com/sheerun/knex-migrate if using Knex.js query builder, or something as simple as https://github.com/tj/node-migrate). But how can I make sure that a schema resulting from my custom migrations match what Prisma expects?

Hello everyone. Some my thoughts on the topic as I've had A LOT of problems with migrations in my workflow: 1. This is a critical feature https://github.com/prismagraphql/prisma/issues/2323 2. Temporary directives is a bad solution for production, it makes impossible to properly deploy services based on Prisma via CI/CD. Migrations versioning is a time-proven approach, but it conflicts with "full latest datamodel" approach. So I see two possible solutions: A) Versioned migrations generation: a developer has a local copy, alters schema as it designed now (changing, migrating, using temporary directives, etc). Then, before pushing to repo and CI, one runs a command that will generate a migration file(s) based on content of

migrations

table (in fact replicating local migration history). Maybe not very robust solution, but should work. One can locally build a migration process using temps and other tricks to alter/move/add structure and data, than "freeze" the process in migration history and target server will replicate this process B) Opposite direction: developers use a versioned migration approach as in other frameworks and after migration server generates and outputs final datamodel as a helper for developers to see actual data state in one place Second variant I see as more solid and controllable, but it fundamentally changes approach to data modeling and requires development of special datamodel-builder syntax and/or special cluster api for this. An example of graphql api for migrations can be something like this:

mutation {
  model(
    name: "Article", 
    addField: [{ name: "slug", default: "", index: INDEX_UNIQUE }],
    changeFeild: [{ name: "old_name", rename: "new_name", nullable: true }]
    removeField: [{name: "old_name"}]
  ) {
    status
  }
}

So the migration will be a file with mutations like this. Also this approach simplifies adding basic data: not seeds with test data, but system-critical data, like initial admin account or initial settings, etc

why can’t this just be easy 😛

Hi I am migrating from graph.cool to prisma. I moved my old definition to the datamodel.graphql. when I deploy, I experience:

➜  prisma-zettelv2-backend git:(prisma) ✗ prisma deploy
Deploying service `zettelv2` to stage `dev` to server `prisma-eu1` !

ERROR: Whoops. Looks like an internal server error. Search your server logs for request ID: eu1:management:cjkpdlfblfo990b30kgyld9ho

{
  "data": {
    "deploy": null
  },
  "errors": [
    {
      "message": "Whoops. Looks like an internal server error. Search your server logs for request ID: eu1:management:cjkpdlfblfo990b30kgyld9ho",
      "path": [
        "deploy"
      ],
      "locations": [
        {
          "line": 2,
          "column": 9
        }
      ],
      "requestId": "eu1:management:cjkpdlfblfo990b30kgyld9ho"
    }
  ],
  "status": 200
}

Get in touch if you need help: <https://www.prisma.io/forum/>
To get more detailed output, run $ export DEBUG="*"
➜  prisma-zettelv2-backend git:(prisma) ✗ prisma info
Service Name: zettelv2

  dev (cluster: `prisma-eu1`)

So I am clicking through the interface for 30 minutes but can not find any server logs to debug my issue.

Hi! I have a question, I still don't really understand how db migrations funcion, am I supouse to use GraphCool migrations with Prisma? I know Prisma configuration support migrations but I just don't see how those work...

not sure if this is the right channel for this, but we’re having a migration ambiguity issue and really can’t figure it out:

while the diff goes like this:

It looks like you had one unnamed relation between show and profile before the migration. And now try to have two named ones after the migration.

But Prisma cannot tell which one was the old one. The easiest solution would be to go from one unnamed relation to a named one in the first step. And in the second step add the second relation.

thanks a lot! it was indeed the fix 🙂

Hello everyone, I’m facing this very weird issue where I did the following: 1. Introduced a new optional Int field to an existing Prisma server 2. Now I want to run a manual migration by using “updateMany” mutation and I get an error “<field> is not defined in the input type” However, I can see that field defined in Playground. Moreover, I am able to run a regular update mutation (not a batch one) on a single item. Also, I am able to run this batch mutation with a local docker. Have any of you encountered this type of behaviour? This is really weird. cc @nilan

Any recommendations for adding a new required field to my datamodel without trashing the exiting data. I found older versions of Graphcool/Prisma had an @migrationValue directive but I don’t see an equivalent in newer versions (my project is currently on v 1.13).

hey folks, currently trying to figure out a way to apply the migrations. Basically, when we need to generate data. I can change the structure using the Prisma directives which work like a charm. I'm wondering which recommendations can you give me, any guide that I can follow? Thoughts!

Can someone please help me with this? I am not sure if this is the right place to ask this question. https://www.prisma.io/forum/t/need-help-in-figuring-out-how-to-access-model-identifiers/5129

If possible would like to have some insights on an issue. For some reason, I'm getting the following error.

Deploying service `default` to stage `default` to server `local`!

ERROR: There is a relation ambiguity during the migration. Please, first name the old relation on your schema. The ambiguity is on a relation between Member and Message. Please name relations or change the schema in steps.

But the issue only happens in the staging environment. We're using the latest version locally and on the staging site (

prisma/1.21.1 (darwin-x64) node-v10.14.1

). We haven't deploy anything to prod. I guess the first time will be ok, but if this issue appears again we don't know how to fixed.

For those who haven't migrated from Graphcool-Framework to Prisma: do it. It's worth every hour it takes.

set the channel topic: https://github.com/prisma/prisma/issues/1263

Hey, caught one weird migration DX hiccup: in the case where you rename a type, but

prisma deploy

fails due to another problem (like a typo), the type renaming still happens and is not rolled back, which then leads to confusing errors when you try to

deploy

again.

Hey! Is there any ETA for the migration feature? We’d really love to use this because it’s a pain currently to update all our backends from release to release. I’ve seen a post that said that there would be some news in the mid of march so I’m curious for any news! 😄 Thanks in advance Carsten

Is there no way to add a default value for a new field on existing items in the database? e.g. My database has 9

Todos

, and I want to add a

important: Boolean!

field to them that defaults to false.