MichalLytek / typegraphql-prisma

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

Empty Input Type for many to many relationship join tables #19

Open rossinicolas opened 3 years ago

rossinicolas commented 3 years ago

After excecute npx prisma generate we have some Input Types that's are empty, so, when i tried to run the nest app i have the following Error:

[Nest] 4976   - 2020-10-16 12:59:05   [ExceptionHandler] Some errors occurred while generating GraphQL schema:
  Input Object type Sgp_ch_turnos_agenteUpdateManyDataInput must define one or more fields.

that's my auto generated file:

import * as TypeGraphQL from "type-graphql";
import GraphQLJSON from "graphql-type-json";
import { JsonValue, InputJsonValue } from "@prisma/client";

@TypeGraphQL.InputType({
  isAbstract: true,
  description: undefined,
})
export class Sgp_ch_turnos_agenteUpdateManyDataInput {
}
MichalLytek commented 3 years ago

Looks like your model does not have any updateble fields, only pks and fks 😕 Can you share the Sgp_ch_turnos_agente model from prisma schema?

BTW, you should map the table name to more readable model name 😝

rossinicolas commented 3 years ago

Hi @MichalLytek , first of all, the table name are comming from an old database that're using for a legacy system in my company ;) LOL

that's the data table model generated by introspection

model sgp_ch_turnos_agente {
  idturno       Int           @default(1)
  idagente      Int
  sgp_agente    sgp_agente    @relation(fields: [idagente], references: [idagente])
  sgp_ch_turnos sgp_ch_turnos @relation(fields: [idturno], references: [idturno])

  @@id([idturno, idagente])
}

Thanks in advance for your assistance

rossinicolas commented 3 years ago

it's a many-to-many relationship between sgp_agante and sgp_ch_turno datatables without aditional fields

image

MichalLytek commented 3 years ago

@rossinicolas Could you also raise the issue in Prisma repo?

It looks like the schema introspection should detect your case and model it as a many-to-many relation in models, without the need of sgp_ch_turnos_agente in the middle 🤔

MichalLytek commented 3 years ago

@rossinicolas Tracked by issue on Prisma repo: https://github.com/prisma/prisma/issues/4004

It has to be fixed upstream. For now you need to manually modify the generated files to fix schema errors.

rossinicolas commented 3 years ago

Thanks.

El El vie, 30 oct. 2020 a la(s) 10:33, Michał Lytek < notifications@github.com> escribió:

@rossinicolas https://github.com/rossinicolas Tracked by issue on Prisma repo: prisma/prisma#4004 https://github.com/prisma/prisma/issues/4004

It has to be fixed upstream. For now you need to manually modify the generated files to fix schema errors.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MichalLytek/typegraphql-prisma/issues/19#issuecomment-719554702, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHMAEEITLOZFABYOMIB6WF3SNK6DBANCNFSM4STQTDIQ .

-- Nicolás Rossi rossi.nicolas@gmail.com

iSplasher commented 3 years ago

Hello, I'm also getting this error and I understand that it's because my model doesn't have any updateable fields?

model RelNode {
    id Int @id @default(autoincrement())

    linkedBy     RelNode[]      @relation("NodeLinks", references: [id])
    linking      RelNode[]      @relation("NodeLinks", references: [id])
    TextFragment TextFragment[]
}

In that case wouldn't it be better and more user-friendly to omit the empty type?

MichalLytek commented 3 years ago

If I omit the type, then I have to propagate that change up in the input types change to exclude a field of that type, etc.

So it's a too complex workaround, for now please bump issue on Prisma to get more attention: https://github.com/prisma/prisma/issues/4004

ZobairQ commented 3 years ago

Hello @MichalLytek, would it be possible to rename this issue to something like "Many to many relationship: join tables causes empty input type" or something like that? it would be easier to spot and we would avoid duplicating the bug 😄

kkaustubhvyas commented 3 years ago

As a workaround I solved this by adding this to my schema

createdAt   DateTime @default(now())

not a solution, but workaround to skip the error

ZobairQ commented 2 years ago

Is there any updates on? Edit: Seems like prisma did resolve their issue

MichalLytek commented 2 years ago

@ZobairQ No, the Prisma issue is still open: https://github.com/prisma/prisma/issues/4004

itpropro commented 1 year ago

Hey @MichalLytek, any updates on this? The prisma issue is closed. I also get these errors with e.g. the following model:

model TemplateResource {
  templateVerId    Int
  resourceId       Int
  templateVersion  TemplateVersion    @relation(fields: [templateVerId], references: [id])
  resource         Resource           @relation(fields: [resourceId], references: [id])

  @@id([templateVerId, resourceId])
}

Error: Input Object type TemplateResourceUpdateManyMutationInput must define one or more fields.

DanielRios549 commented 1 year ago

Any update? I am still getting errors related to this issue

nikhilswain commented 1 year ago

@MichalLytek sir, any updates on the issue or any work around for this, cause we're still getting the error in my case it's saying the field is undefined

image

eliaperantoni commented 1 year ago

This issue was quite a roadblock for a project at my job. We have this database that contains a few join tables with no additional fields, causing the Input Object type ... must define one or more fields. error. Modifying the Prisma schema was unfortunately not an option because we cannot add columns to the database itself. Instead, I figured I could just add a dummy field to the generated TypeGraphQL input type.

After all, if you go deep enough down the rabbit hole, you'll see that it's all caused by an (arguably arbitrary and artificial) constraint in the GraphQL specification. There was interest in changing the spec (https://github.com/graphql/graphql-spec/pull/606) but, for some reason, it all died out in the end. The current state is that some GraphQL implementations do force input object types to have at a field, and others simply don't care. Among those that do follow the spec more closely, https://github.com/graphql/graphql-js is the one causing the issue here.

Going back to the workaround, I've forked a new @ono-lean-logistics/typegraphql-prisma NPM package which merely adds a dummy _ nullable int field whenever a type doesn't have any field already (which should only occur in *UpdateManyMutationInput types).

Because this is a very quick n' dirty solution, I'm not 100% sure that it deserves a PR. But it's also true that join tables are an essential component of relational databases and one shouldn't encounter an issue such as this to begin with. @MichalLytek What do you think?

eliaperantoni commented 1 year ago

Also, I think the "blocked" label should be removed now, as the Prisma issue that was marked as the culprit is now closed.

MrDonArmando commented 1 year ago

This is a serious blocker in a project I work on.



Solutions like
 createdAt DateTime @default(now())
 doesn’t seem to be working.



My coworker found that setting useUncheckedScalarInputs to true 

solves this issue. 

 

With that option set to true I see that there're 2 inputs generated

@MichalLytek any thoughts on this solution?

dahaupt commented 7 months ago

I guess we should focus on a solution which removes the empty input type (and related mutations?) from the GraphQL schema. As Michal already noticed in the linked Prisma issue, an update operation without any data is senseless. I will invest some time here on the weekend.

Rechdan commented 1 week ago

Fixed after using: https://prisma.typegraphql.com/docs/basics/configuration#emitting-transpiled-code