Add the ability to add a where clause for "one-to" side of "one-to-one" and "one-to-many" #16049
Labels
kind/feature
A request for a new feature.
team/client
Issue for team Client.
topic: client api
topic: prisma-client
topic: relations
Problem
I'm trying to build a tool ontop of Prisma that handles access control defined via a ruleset.
What I currently have is the ability to block certain tables from being queried as well as only returning a subset of tables that are accessible by the defined rules.
However while implementing I found that there is no
where
argument available for relations that are on the "one" side from a "one-to-many" relationship (or both sides with a "one-to-one" relation)An example query that I would want to send is here:
This obviously tells me (correctly) that
where
does not exist onTrack
but without having awhere
clause there, my only other option is to fetch every record that is required for checking the rule and check this in userspace instead of having this be dealt with in the database layer.This becomes a problem with a large amount of data as the rules can use relations and thus making me load a lot of unnecessary data into memory to then filter out again.
Suggested solution
Add
where
to the "one" side of relations so it can benull
depending on if thewhere
matches or notAlternatives
There is the alternative that I would add the
where
clause higher up on theinvoiceLine
, but I want to fetch the data for theinvoiceLine
but haveTrack
be null in this case. If this was my own application I could make assumptions in the way I query but since this is aimed to be a general purpose tool I can't push that assumption to the users.I also cannot make the
Track
be a optional field (if this is why I don't have awhere
clause) because I want the database to validate that data is correctly inserted.A last resort solution would be to detect when I hit a "boundary" like this and get all IDs and make a subsequent
Track.findMany
but I'd like to not do that if possible and make a single roundtrip to the database instead for latency reasonsAdditional context
The Prisma schema as well as the migrations for some test data are available here: https://github.com/firatoezcan/typegraphql-prisma-cms/tree/nexus/apps/api/prisma
Schema
The text was updated successfully, but these errors were encountered: