MichalLytek / typegraphql-prisma

Prisma generator to emit TypeGraphQL types and CRUD resolvers from your Prisma schema
https://prisma.typegraphql.com
MIT License
891 stars 113 forks source link

Possibly Incorrect Generated Type for `disconnect` in 0.27.1 #426

Open andrewleverette opened 1 year ago

andrewleverette commented 1 year ago

Describe the Bug

I recently updated the typegraphql-prisma dependency from 0.25.1 to 0.27.1 and the prisma dependency from 4.16.2 to 5.4.2. After running the generation, I noticed several type errors in the application regarding the use of disconnect in relation queries. The way I had been using disconnect was to set the property to true when I needed to set a foreign key value on a table to null. I checked the generated types after updating to 0.27.1 and the type of the disconnect property is a where input type. Before the update, the type was a scalar boolean input type. Is the type of the disconnect property on relations correct in the new release of typegraphql-prisma? The prisma documentation shows that setting the disconnect property to true is valid. If this is correct, how would I disconnect a related record if I don't have the foreign key id at the time of the query? Basically, I just need to be able to set the foreign key value to null.

To Reproduce

Below is a minimal example to show what I'm referring to.

schema.prisma (which is the same in both versions)

model QuestionTemplate {
  QuestionTemplateId                  Int                              @id @default(autoincrement())
  IndicatorTypeId                     Int?
  IndicatorType                       IndicatorType?                   @relation(fields: [IndicatorTypeId], references: [IndicatorTypeId], onDelete: NoAction, onUpdate: NoAction, map: "fk_QuestionTemplate_IndicatorType_IndicatorTypeId")

model IndicatorType {
  IndicatorTypeId                  Int                       @id @default(autoincrement())
  QuestionTemplate                 QuestionTemplate[]
}

Generated Update Input Type for 0.25.1

export declare class QuestionTemplateUpdateInput {
    IndicatorType?: IndicatorTypeUpdateOneWithoutQuestionTemplateNestedInput | undefined;
}

export declare class IndicatorTypeUpdateOneWithoutQuestionTemplateNestedInput {
    create?: IndicatorTypeCreateWithoutQuestionTemplateInput | undefined;
    connectOrCreate?: IndicatorTypeCreateOrConnectWithoutQuestionTemplateInput | undefined;
    upsert?: IndicatorTypeUpsertWithoutQuestionTemplateInput | undefined;
    disconnect?: boolean | undefined;
    delete?: boolean | undefined;
    connect?: IndicatorTypeWhereUniqueInput | undefined;
    update?: IndicatorTypeUpdateWithoutQuestionTemplateInput | undefined;
}

Generated Update Input Type for 0.27.1

export declare class QuestionTemplateUpdateInput {
    IndicatorType?: IndicatorTypeUpdateOneWithoutQuestionTemplateNestedInput | undefined;
}

export declare class IndicatorTypeUpdateOneWithoutQuestionTemplateNestedInput {
    create?: IndicatorTypeCreateWithoutQuestionTemplateInput | undefined;
    connectOrCreate?: IndicatorTypeCreateOrConnectWithoutQuestionTemplateInput | undefined;
    upsert?: IndicatorTypeUpsertWithoutQuestionTemplateInput | undefined;
    disconnect?: IndicatorTypeWhereInput | undefined;
    delete?: IndicatorTypeWhereInput | undefined;
    connect?: IndicatorTypeWhereUniqueInput | undefined;
    update?: IndicatorTypeUpdateToOneWithWhereWithoutQuestionTemplateInput | undefined;
}

Expected Behavior

I expect the generated types to be the same or at least match what Prisma is showing.

Logs No applicable logs

Environment (please complete the following information):

Additional Context No additional context that I can think of as relevant

MichalLytek commented 1 year ago

This is a big problem with graphql not supporting input union while prisma does. So they accept boolen or filter object while in graphql we can't, so in most cases it accepts the object but for this case it might be problematic.

andrewleverette commented 1 year ago

Thank you for the quick response. So this is a limitation of GraphQL? Do you know of a good workaround? Or is there any work that could be done to resolve this issue? I would be open to contributing, but not sure where I would start with this.

Also, just for reference. I found this document that seemed relevant -> https://github.com/graphql/graphql-wg/blob/21e8ecd30934843cbb175758eaa3d80325cd0929/rfcs/InputUnion.md

mvarendorff commented 1 year ago

There is also the oneOf directive on inputs which is still not part of the official spec but supported by most tooling afaik. Maybe that could work here? I am not sure if that is an option since it would mean an object with two fields instead of a single field passed directly as argument.

MichalLytek commented 1 year ago

@geisterfurz007 The @oneOf does not make an input union. In this case, we can't have disconnect field of type Boolean | SomePrismaType. We would need to split them into disconnectBoolean: Boolean and disconnectComplex: SomePrismaType and then in resolver merge them into disconnect Prisma Client query object.

andrewleverette commented 1 year ago

Is it possible to distinguish between relational types like one-one, one-many, etc? It seems like in the cases of a one-one relationship, the disconnect field could be the boolean and a where input type in the other cases. I could be missing something though.

andrewleverette commented 12 months ago

For further information, I upgraded to 0.27.0 and this issue does not exist in that version.

shawnjones253 commented 11 months ago

For further information, I upgraded to 0.27.0 and this issue does not exist in that version.

double-checking, you don't have this problem with 0.27.0?

we do have this problem with:

"typegraphql-prisma": "0.27.0",
"prisma": "4.16.2"
andrewleverette commented 11 months ago

@shawnjones253, I confirmed we have the same problem in 0.27.0. There was an issue in my build process that was pulling an older version, so we were getting a false positive. We ended up just reverting 0.25.1.