hayes/pothos
View on GitHubprisma plugin select with expose does not work properly if fetched through resolveReference
Open
#1,321 opened on Oct 22, 2024
documentationgood first issuehelp wanted
Repository metrics
- Stars
- (2,609 stars)
- PR merge metrics
- (PR metrics pending)
Description
Consider a federated graph where in one graph you declare an entity like this:
export const ProjectRef = builder.prismaObject("Project", {
select: { // to load only the necessary data, you can select the fields you need
id: true,
name: true
},
fields: (t) => ({
id: t.exposeID("id"),
name: t.exposeString("name"),
slug: t.exposeString("slug") // exposeString automatically selects the exposed variable, so you don't need to explicitly add this to `select`
}),
});
builder.asEntity(ProjectRef, {
key: [
builder.selection<{ id: string }>("id"),
],
resolveReference: (key) => {
return prisma.project.findUnique({
where: {
id: key.id
},
// pothos correctly sets the type so i have to set the same `select` as in the objectRef
select: {
id: true,
name: true
}
});
},
});
If this entity is resolved in another graph and therefore resolveReference is called, slug will yield an error:
"Cannot return null for non-nullable field Project.slug.",
It turns out that t.exposeString("slug") does not properly append the select in this case.
Workarounds:
- not using expose, but instead a normal field resolver:
slug: t.string({
select: {
slug: true,
},
resolve: (parent) => parent.slug,
}),
- not using select in the
resolveReferencecall. That means you will lose the efficiency gains there