MichalLytek / MichalLytek/typegraphql-prisma

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

Open
#474 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
918
Forks
130
PR merge metrics
No merged PRs in 30d

Description

**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:
```prisma
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:
```ts
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:
```gql
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

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reproducing the generated GraphQL schema for the User and Post models shown in the issue, then trace how nested relation update inputs are generated for Prisma's set operation. Compare the generated set field types with Prisma's documented input shape. Done means set accepts raw relation objects rather than filter-operator objects, with coverage for the reported one-to-many case.

Written by the indexing model from the issue text.

Assessment

Tech stack
graphql, typescript
Domain
api
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.