Issue with relation If field is not null the input is required in mutation

[maximilianorom77]

Hey!

I have a model Client that has a many to one relation with Tenant, here there is the model and the generated input for the createClient mutation: As tenantId and Tenant cannot be null the generated input ClientCreateInput makes both fields required

model Client {
  id       String @id @default(dbgenerated("uuid_generate_v4()")) @db.Uuid
  tenantId String @default(dbgenerated("uuid_generate_v4()")) @db.Uuid <--- both fields cannot be null
  Tenant   Tenant @relation(fields: [tenantId], references: [id])      <--- 
  User     User[]
}

input ClientCreateInput {
    tenantId: String!                         <--- both fields are required
    Tenant: ClientTenantCreateRelationsInput! <--- passing both in a mutation to create a
    User: ClientUserCreateRelationsInput           Client leads to an exception
}

So if I only pass one I get this error

And if I try passing both I get a timeout exertion and a hidden error message in Cloudwatch

My "solution" was to make the fields nullable with the ? mark

model Client {
  id       String @id  @default(dbgenerated("uuid_generate_v4()")) @db.Uuid 
  tenantId String? @default(dbgenerated("uuid_generate_v4()")) @db.Uuid <--- both fields are nullable
  Tenant   Tenant? @relation(fields: [tenantId], references: [id])      <--- 
  User     User[]
}

that way the input for those fields are optional

input ClientCreateInput {
    tenantId: String                         <--- both fields are optional to pass in the mutation
    Tenant: ClientTenantCreateRelationsInput <--- just providing one is enough
    User: ClientUserCreateRelationsInput
}

And if I provide only the Tenant I am able to create the Client and connect with a Tenant

same if I provide the tenantId

making the field nullable in the model to make the input optional is not what I want, I would prefer a directive that let me set the field as not null and in the same time the input for the create mutation to be optional

[maoosi]

Thanks for reporting @maximilianorom77 - this should be fixed in the next release.