You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The consequence is in the resolver, when using it like so :
t.prismaField({type: User,// used hereargs: {input: t.arg({type: UserSelfCreateInput,required: true})},resolve: async(query,parent,{input: payload},context)=>{// `payload` resolves to `Prisma.UserCreateInput`constcreatedUser=awaitdatabase.user.create({// So compiler is happy heredata: payload,});returncreatedUser;},}),
And the generate GraphQL is like so :
input UserCreateInput
(empty input)
Which lead to runtime errors; because the GraphQL schema is not consistent to what is passed to the resolver.
I observed the exact same behavior with any kind of more complex configuration, example :
exportconstUserSelfCreateInput: InputObjectRef<Prisma.UserCreateInput>=builder.prismaCreate('User',{name: 'UserCreateInput',fields: (t)=>({contactEmail: t.string({required: true,validate: {schema: z.string().email()},}),name: t.string({// This shouldn't be accepted as it's not nullable in the modelrequired: false}),}),});
My observation is that prismaCreate.fields is basically just not producing something type-checkable with a type like so :
For a lot of create inputs, you want to mix user provided inputs with things provided in the resolver, it is rare that the user is providing all fields in their input. This does lead to some lack of type-saftey.
I am not against having the types be more accurate here, but getting this to work reliably with prisma's input types without compromising other parts of the developer experience is tricky and there are higher priority features I am working on right now, so I probably won't be able to improve this until after v4 releases
Hi !
Running through the documentation, I applied the chapter "Creating input for mutations" and found a strange behavior :
This perfectly TS compile, while
Prisma.UserCreateInput
is like this :The consequence is in the resolver, when using it like so :
And the generate GraphQL is like so :
(empty input)
Which lead to runtime errors; because the GraphQL schema is not consistent to what is passed to the resolver.
I observed the exact same behavior with any kind of more complex configuration, example :
My observation is that
prismaCreate.fields
is basically just not producing something type-checkable with a type like so :The text was updated successfully, but these errors were encountered: