Open marktani opened 6 years ago
Comment by marktani Friday Dec 01, 2017 at 14:41 GMT
Thanks a lot for the detailed write up, @aloof-ruf! We're currently discussing a new migrations design, would love to hear your insights there: https://github.com/graphcool/framework/issues/1263 🙂
Issue by aloof-ruf Monday Nov 27, 2017 at 17:19 GMT Originally opened as https://github.com/graphcool/prisma/issues/1334
Current behaviour Right now, when you have previously locally deployed your types with a relation, and then try to locally deploy an update that removes the previous relation but keeps the name of it and now references a scalar type you'll get the following misleading error:
You can only create scalar fields and <scalar type here> is not a scalar value. Did you intend to create a relation?
Reproduction You can reproduce this with the following steps:
mkdir graphcool_local_fail; cd graphcool_local_fail; graphcool init
types.graphql
and uncomment thePost
type along with theposts
relation in the User type. The file should look like this:type User @model { id: ID! @isUnique name: String dateOfBirth: DateTime
Uncomment below - you can declare relations between models like this
posts: [Post!]! @relation(name: "UserPosts") }
Uncomment the model below as well
type Post @model { id: ID! @isUnique title: String!
Every relation also required a back-relation (to determine 1:1, 1:n or n:m)
author: User! @relation(name: "UserPosts") }
The following types define the data model of the example service
based on which the GraphQL API is generated
type User @model { id: ID! @isUnique name: String dateOfBirth: DateTime
posts: Int }
Uncomment the model below as well
type Post @model { id: ID! @isUnique title: String! }
Expected behavior? The current way around this is to completely remove the field (in the case above, remove
posts
) and then insert it again as whatever you want. I feel Graphcool should either handle this change or give a better error message such as"posts" field already references a relation. Please choose another name for your scalar field
. Think about potentially ambiguous field names likedata
, where at one time it references a particular model, but over time the developers decided to just reference a String. I feel like a more explicit error would help those developers.