It seems the default directive only applies to newly created items?

I know there’s a RFC for migrations, but is everyone really doing stuff like setting new fields as nullable, deploying, running manual migration scripts, marking the field as non-nullable and deploying again?

hey! We’re using Prisma in production since almost nine months now and want to add a required

toOne

-Relation to our datamodel. This issue https://github.com/prisma/prisma/issues/2323 describes the current migration options and how to set default values etc., but I can’t figure out, how to connect another type by default (e.g. a user by the unique mail-adress). Is there any possibility to do this via the Prisma migrations? We’re running over a dozen backends which I’d had to migrate manually, if this isn’t possible.

Question about migrations: I'm not sure if I just misunderstood how migrations work, but I set up Prisma on a server that had a MySql database and it migrated all types and fields, but none of the actual data... Do I need to do something else to get the data?

Prisma is basically set up, it's just empty:

I realize now after much reading and looking that data migration isn't a part of Prisma, apologies.

At this point really the only thing stopping myself and my team from using prisma on virtually all of our graphql back ends is the lack of migration support. We’ve tries to integrate knex, but issues with introspection prevented that from being viable. Looking forward to Prisma2/Lift migration to see if those can prevent the lock-in the lack migrations causes!

When I deployed my converted schema from GC to Prisma I got this error:

Valid values for the strategy argument of `@scalarList` are: RELATION

So I added

@scalarList(strategy: RELATION)

and it worked. But when I inspect my DB I see that the related table is empty after import from GC where there are values for this field. What happens is that for MyTable with myField: [String!] @scalarList(strategy: RELATION) another table is created with name: MyTable_myField with columns: nodeId, position, value. I got 4 different tables with this structure and all are empty after import. Any ideas on how I could fix this?

Does anyone know if there is a smooth way to extract/export resolvers from GC and convert them into local resolvers calling Prisma?

I get these kind of errors when trying to run nexus-prisma:

nexus-prisma.ts:2580:25 - error TS2694: Namespace '"/.../prisma-client/index"' has no exported member 'SomeExample'.

Did I generate the prisma-client in the wrong way? Do I miss to add something to my datamodel.prisma?

Is there an equivalent to GC meta requests in Prisma? I.e. where you can get the count of a query without fetching all of the data

I am migrating from graphcool to prisma and I am trying to run “prisma import” with my GC data a second time and I get:

Cause: .SQLIntegrityConstraintViolationException: (conn=567) Duplicate entry 'cjmlq59d62tvm01838cb26o1h' for key 'PRIMARY'"

I do this because I want most of my prod data to be in my prisma DB before launch and on launch day just import the recently added data. Does anyone know if it is possible to tell prisma import to ignore existing entries?

Hello everyone, I'm having an issue while importing/exporting data from a prisma-dev service to a prisma-heroku (server + db) I successfully imported the datamodel and the nodes + lists but when it comes to relations, a bunch of errors regarding missing foreign keys are thrown in the terminal (e.g. "Failure inserting into relationtable IntegrationAuth with ids StringIdGCValue(cjxucf9ksgkaf0b70omdt0lzx) and StringIdGCValue(cjxucf9kvgkag0b702uah4ssa). Cause: insert or update on table \"IntegrationAuth\" violates foreign key constraint \"IntegrationAuth_setup_fkey\"\n Detail: Key (setup)=(cjux6rrgn0rk50b22erj4sym5) is not present in table \"IntegrationSetup\".",). There are about 100 of them and then, when I look at the databrowser, all the data is there but, logically, there is no relation. I tried several things I found on the internet and nothing seemed to work Could someone please help me, I don't really know where to look at to solve that problem? Thank you very much 🙂

Hey @arthur so their import tool doesn’t really work the greatest. I found what I usually had to do was just export the data from the database with a native database tool. For MySQL or Postgres you can use TablePlus. You have to usually export the data from the dev service, and import into a local docker container of a DB. And then do a TablePlus export, and do a heroku data upload as if you were just coming from the database directly rather than funneling it through using their export. Everyone is having tons of issues with their import/export tool with the relations specifically. I had a bunch when I was switching from graphcool to prisma 1

Also having issues with exports. Running into this issue: https://github.com/prisma/prisma/issues/4216 What is the best way to back up and restore from an older (but stable) Prisma setup? I have to access my live container directly? So far I've done everything through the Prisma CLI and have all my operations set up with that. If I could just figure out how to make export-import work (which is has before), I'd be solid. Don't plan to even bump versions or make any changes.

Hi folks, we've started building a project using prisma and have some questions on the workflow. Having worked for years with powerful ORMs like Django or Ruby on Rails, it feels weird to have my database, schema, and migration disconnected. We tried to setup our schema with Prisma migrate and the Prisma introspection, but with both approaches we keep running into bugs which slow us down a lot compared to other stacks. Writing migrations in db-migrate and then introspecting the database to get a Prisma schema feels odd, as there is no single place for a model anymore where I could also store meta data like field names, field labels, etc. Field descriptions could certainly be added on the GraphQL layer, but then again, I'm creating another place with "model information". Are we missing something here? How do you manage this or which ORM are you using? Or is prisma just not there yet? Prisma migrate seems to go into the right direction but is still experimental. From using it now for a few weeks now there seem to be a lot of things missing that e.g., Django's ORM does for you out of the box. I tried to find more information when prisma migrate is supposed to move out of the experimental status, but couldn't find anything. Maybe, somebody can shed some light on my questions here. Thanks already for any answers.

Hi! I did a deploy this morning and everything seems to turn out well except for one thing. One of the models, that weren’t referenced in the migrations that were applied, doesn’t have the column “type” anymore. Is it so that type is a reserved word in prisms? Looking at my db backup it used to work (it was there before the migration)

Hi Is it (or will it be) possible to insert a rows (data) with prisma migrations?

It may fit better in migrations...

Additional issues: how to migrate the custom resolvers from graphcool to prisma?

Hi, has anyone experienced data loss on migrations?

We ran a few migrations recently causing data loss, specifically in many to many relations

Is there a way to backfill existing records for a migration? Say I'm adding a new relation column like

author_id

on a post, how can I (for sake of asking the question), execute a select few to have one author_id another others a different author_id for a migration?

Hi! I was planning to use prisma migration as a migration tool for my app. However, it seems like this feature is still experiemental. I'm using Node.js and postgresql for the backend. Are there any recommendation (other than knexjs) as for alternatives? Thanks!

Hi! We've been using Prisma 2 since the beta and something weird has happened twice now. We have two models that contains properties/fields with the name "type" (without " ofc). One of those two models sometimes loose it's db column called type. It just disappears during a migration. And it always happens on one of those two, but it doesn't happen every time we run migrations. Any clues?

set the channel topic: Use this channel for anything related to prisma migrate (Prisma 2 - specific).

@janpio if you're rethinking migrations, here's a question about best practise. How would someone do a deploy? You don't want to migrate while still running the old code, because it could crash. On the other hand, you don't want to deploy new code and migrate after that, because of the same reason 🙂 I thought about one possible solution. Imagine if there's a pre-deploy migration where it would do all the non-destructive migration step such as adding tables/column. And then there's a post-deploy migration step where it would delete old columns, copy date from an old column to a new one (in case you have renamed a column) etc

that way it wouldn't crash trying to access tables/columns that doesn't exist anymore etc.. But I have only put like 10 minutes in to that thought/solution

Seeing that introspection is the recommended migration strategy, will prisma introspect be a first-class citizen once migrate is stable? I see things such as

@map

directives being lost from introspect, so does it mean that to support those things we will have to move from existing migration solution (eg. knex or umzug) to prisma migrate?

Want to test a new prototype for DB migrations? Hello everyone, <!here>! We’ve been busy working on our solution for database migrations. We’d love to get your feedback on a prototype we’ve built. We are looking for users who are using or not prisma migrate today. If you can’t use prisma migrate today, i.e. need some DB feature which is not supported, we’d love to show this to you too as we think you might like it! 😉 If you are interested, please DM me to schedule a call (ideally this week). We are looking to fill 5 slots, first come first served. Don’t miss out! We are excited to hear your thoughts on this new direction! 🚀