Prisma1: Not able to create relation-only Type

[maxdarque]

Current behavior
I am using the graphql create with the typescript-advanced to create a graphql-yoga server with a prisma instance on eu-west-1. Link to package.json

Here's my data model

type User {
  id: ID! @unique
  email: String! @unique
  password: String!
  name: String!
  activativationCode: AccountActivationCode
}

type AccountActivationCode {
  id: ID! @unique
  createdAt: DateTime!
  user: User
}

When I run yarn prisma deploy, I get the following error:

Checking, if schema file changed !
 ▸    AccountActivationCodeUpdateWithoutUserDataInput fields must be an object with field names as keys or a function which returns such an object.

This data structure used to work fine on graphcool-framework. I added another variable and the deploy worked:

type AccountActivationCode {
  id: ID! @unique
  createdAt: DateTime!
  user: User
  withthisvariableitworks: String
}

Reproduction

https://github.com/maxdarque/prisma-issue-1817

Expected behavior?
This used to deploy fine to graphcool-framework

[lueurxax]

Remove createdAt: DateTime! from data model

[maxdarque]

@lueurxax I don't follow. I need createdAt: DateTime!.

[Saeris]

I'm running into similar issues with my datamodel.

Although now removed from the above, I had a type BlockedUser on my User type, which had this shape:

type BlockedUser {
  createdAt: DateTime!
  user: User!
}

And I was getting the same error, fields must be an object with field names as keys or a function which returns such an object.

Deleting the offending type and redeploying didn't solve the issue, as now I'm getting it for my Icon type, which can be found in the datamodel linked above. Removing the createdAt field didn't make any difference either.

I'd like to add, the only reason why I've got these types in the first place is because of the rules surrounding relationships. If I use a custom type, such as User, in more than one field on a given type, I'm required to use the @relation directive to link two fields of the same type to clear up ambiguity. This isn't ideal in the case that there is no other field to pair with, or the paired fields are of different types. I can create a separate issue for this. Just thought it might be related since that's the context in which I ran into this error to begin with.

[Fi1osof]

createdAt and updatedAt - prisma`s reserved fields. Rename it, for example, created_at.

[Saeris]

The use of createdAt and updatedAt shouldn't be an issue here. The boilerplate projects use these fields with absolutely no issue, as can be seen here:

https://github.com/graphql-boilerplates/node-graphql-server/blob/master/advanced/database/datamodel.graphql

Including them on a type merely exposes those columns so that they can be queried.

[moritzmorgenroth]

This seems to be a bug, I'm running into the same issues here. There is no logically explanation for this, this is bad behavior. I tested it with

type Mother{
  id: ID! @unique
  children: [Child!]!
}
type Child{
  id: ID! @unique
  mother: Mother!
}

, which reproduces the bug. It has nothing to do with a changing schema file like the console output suggests, as it also occures after running a clean prisma delete and redeploying with prisma deploy. Removing the Child reference to the mother worked as a workaround for me. This seems to be a problem with the way two way bindings are processed.

Would be great if this could be resolved soon as it is a major bug. THX!

[marktani]

Yes, I can confirm that this is a bug. You can add any scalar field (like dummy: String) to work around this issue.

What I am curious to know, is the deploy successful? That is, does the Prisma API change?
This would mean that this is a bug in either prisma CLI or graphql prepare.

[moritzmorgenroth]

From what I am seeing, this bug occurs in the local code generation process, the deployment to the server seems to work just fine.
This seems to also be independent of typescript code generation, as removing
prepare-binding: output: src/generated/prisma.ts generator: prisma-ts
from the config does not work around the issue.

@marktani What do you mean by your workaround? I don't see this solving the issue.

[marktani]

What happens when you run graphql prepare?

[moritzmorgenroth]

Works as expected, outputs

Bindings for project database written to src/generated/prisma.ts

[marktani]

Hmm, that was running the binding generation, but not the schema bundling.
What about graphql prepare -p database -o src/generated --bundle --save?

[marktani]

For reference, I am pretty sure this is a bug in graphql prepare.

With the workaround I mentioned above, this is what I meant:

type Mother {
  id: ID! @unique
  children: [Child!]!
  dummy: String
}

type Child {
  id: ID! @unique
  mother: Mother!
  dummy: String
}

This should solve the issue.

[moritzmorgenroth]

Also successful:

Bundled schema for project database written to src/generated/database.graphql Saving configuration for project database to .graphql Configuration for project database saved to .graphqlconfig.yml

Mhh, Im not sure where things are going wrong... Looks like graphql prepare issue, but all graphql prepare commands work fine. Might just be a Prisma CLI issue expecting some generated types that are not there. A If, at all, graphql prepare is causing the issue, then because its generating to little types. This, however, I dont think probable, as there were never any issues in older Prisma releases- or nobody ran into them.

[moritzmorgenroth]

You work around does not work for me btw.
I ran into this issue with much more complex type definitions, only removing one end of the two way reference worked for me.

[marktani]

Interesting, thanks for that information! Looks like my proposed workaround solved the issue in the original post and not in your situation.

This might be a version mismatch of the local graphql dependency. What is your graphql version?

Is this a working workaround in your situation:

• prisma deploy
• graphql prepare -p database -o src/generated --bundle --save

?

[moritzmorgenroth]

graphql --version
2.12.4

No, this does not resolve the issue. I dont think that is is a local dependency issue.
the schema.graphql file does not get generated by prisma deploy when the error is thrown as described before:

Checking, if schema file changed !
 ▸    MotherUpdateWithoutChildrenDataInput fields must
 ▸    be an object with field names as keys or a
 ▸    function which returns such an object.

The command you suggest does not run at all complaining that it can not find the schema file.

ENOENT: no such file or directory, open .XXX/src/generated/prisma.graphql

[notadamking]

The combination of this issue, #1907, and #83 not being finished has caused my data model to become bloated full of unnecessary and unwanted fields/data. About 50% of my data model is unnecessary/dummy code, but it's required due to these bugs/features not being complete. Very frustrating.

[amirhouieh]

running almost into same issue I guess:

type MediaFile {
  ...
  page: Page!
}

type Page {  
  ...
  thumbnail: MediaFile
  media: [MediaFile!]!
}

Error on prisma deploy

    ✖ The relation field `thumbnail` must specify a `@relation` directive: `@relation(name: "MyRelation")`
    ✖ The relation field `media` must specify a `@relation` directive: `@relation(name: "MyRelation")`

[marktani]

@amirhouieh, your issue is unrelated and is actually expected behaviour. When you have two relation fields to the same type, you need to distinguish them using the @relation directive. Please open a new issue if you want to discuss this further, as it's a separate topic.

We will be looking into this soon @moritzmorgenroth @adamjking3.

[amirhouieh]

@marktani thanks. I read the docs again and actually there is an example laying out the same use case.

[marktani]

This looks to be closely related to this: https://github.com/graphcool/prisma/issues/1981.
I'll write an update there shortly.

[marktani]

This is fixed here: https://github.com/graphcool/prisma/pull/2005

You can check this now on the unstable channel @maxdarque @lueurxax @Saeris @Fi1osof @moritzmorgenroth @adamjking3. Let me know if you have any problems 🙂

[marktani]

This is now fixed and available in 1.4.0 🙂