-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Always set rejectOnNotFound
to false
#98
Comments
@jpulec can you clarify what you expect to happen here? Are you saying you don't want the projected field to throw? More specifically: Even though you want a |
I did a little digging into this, and I actually believe it's an issue with prisma. When you set import { PrismaClient } from "@prisma/client";
const prisma = new PrismaClient({
rejectOnNotFound: {
findUnique: true,
},
});
await prisma.post.findUnique({ where: { id: 'test-id' } }).user({ rejectOnNotFound: false }); // This isn't a real option And even if the above did work, I'd still need a way to pass that option to I really might need to take this up with the I think ideally, prisma shouldn't treat fluent api calls that are chained from |
Could you explain a bit more your rationale for why the behaviour between the two should diff? (I work at Prisma by the way) |
Sure. I think the challenge is that I can't override the calls separately, which is more of an issue when setting However, I find that it's pretty common to expect a The way I think of it, doing the fluent API call is conceptually to me a second lookup (and sometimes is actually a separate query, if I'm not mistaken?), which means I have different expectations around whether or not I'm okay with it being nullable. Please correct me if I'm wrong, but I also believe if I did the following: await prisma.post.findUnique({ where: { id: 'fake-id'}, rejectOnNotFound: false }).user();` and the result was |
From my understanding, if you provide a nullable relation (like in this case |
Here's How I'm seeing the mapping:
I think NP should ignore Does this make sense? |
I think that's probably a good start. Maybe it's worth making it configurable, but I think just always setting |
rejectOnNotFound
Set FailsrejectOnNotFound
to false
I started the PR with updated docs. Feedback welcome https://github.com/prisma/nexus-prisma/tree/feat/reject-on-not-found-false#projecting-nullability. |
@jpulec Please bring a use-case in the future when you have one. Also remember you can override the NP resolvers with your own logic fwiw. |
🎉 This issue has been resolved in version 1.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Description
It seems that there's some sort of interaction between setting
rejectOnNotFound: true
forfindUnique
globally and how nexus-prisma tries to resolve relations. Because nexus-prisma uses prisma's fluent API, it performs afindUnique
for the parent model, and then tries to fetch the relation via the fluent API, which throws aNot Found
error if the relation is null.The above causes nexus-prisma to try to run
prisma.post.findUnique({ where: { id: <ID> } }).user()
which will throw a not found error if it is null.Happy to provide any more explanation.
The text was updated successfully, but these errors were encountered: