Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

set in nested writes for one to many relationship has incorrect field types #474

Open
valerii15298 opened this issue Nov 12, 2024 · 0 comments

Comments

@valerii15298
Copy link

valerii15298 commented Nov 12, 2024

Describe the Bug
When trying to set(https://www.prisma.io/docs/orm/reference/prisma-client-reference#set) posts of the user via generated graphql, schema has invalid types for fields in set

To Reproduce
Imagine this schema:

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

generator typegraphql {
  provider = "typegraphql-prisma"
}

model User {
 id Int     @id @default(autoincrement())
 name String

 posts Post[]
}

model Post {
 id Int     @id @default(autoincrement())
 name String
 user   User @relation(fields: [userId], references: [id])
 userId Int
}

then with prisma you can do something like this:

prisma.user.update({
  where: { id: 1 },
  data: { posts: { set: [{ id: 1, name: "hello" }, { name: "world" }] } },
});

But typegraphql prisma generates graphql schema so that query looks like this:

mutation {
  updateOneUser(
    where: {id: 1}
    data: {posts: {set: [{name: {equals: "why operators here???"}}]}}
  ) {
    id
  }
}

Which is not logical at all. name property should be just a string and not a object with operators from where clause.

Expected Behavior
properties inside set should be raw values and not objects with operators properties

Environment (please complete the following information):

  • typegraphql-prisma version 0.28.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant