-
-
Notifications
You must be signed in to change notification settings - Fork 176
Open
Labels
documentationImprovements or additions to documentationImprovements or additions to documentationgood first issueGood for newcomersGood for newcomershelp wantedExtra attention is neededExtra attention is needed
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
resolveReference
call. That means you will lose the efficiency gains there
Metadata
Metadata
Assignees
Labels
documentationImprovements or additions to documentationImprovements or additions to documentationgood first issueGood for newcomersGood for newcomershelp wantedExtra attention is neededExtra attention is needed