it seems like the where filter in the resolver is ...
# prisma-whats-new
r
it seems like the where filter in the resolver is being overridden by the where filter in the client query because I’m passing in all of info as the second argument to
ctx.db.query.rules
w
usually the args are passed in via a mutation like
Copy code
mutation {
createUser(firstName: "Robert")
}
I assume things like
where
,
orderBy
, etc. are considered the args in a query
So in this case, you'd have a
{where: ....}
in your args, but no
gameId
r
yes, this is true, but even so. If I use
{where...}
from args and try to add something to it before using it in the db query, it still does nothing
by does nothing, it means that the initial where filter is used, not the extended one
w
this sort of function is working for me:
Copy code
async function me(parent, args, ctx, info) {
    const fullAuth0Id = await getAuth0Id(ctx)
    return ctx.db.query.user({ where: { fullAuth0Id } }, info)
}
even though the client doesn't specify their id, it gets the correct user, and all the data the client specifies
r
yes but are you also using a where filter in the client query?
w
no, just selecting fields
r
yeah, sorry if I wasn’t clear. My question is how to combine the client-side where filter with a server-side where filter.
or if its even possible
w
i kind of assumed that the client's where query would only search the subset of data selected by the explicit one that I passed in as the first argument
r
well, so I can’t really explain why this still works:
Copy code
rules(parent, {where}, ctx, info) {
    return ctx.db.query.rules({}, info)
  },
w
because the client's query info is in the
info
object
r
right
w
you want to lock them to an
authorId
right? Like, only if they are the author can they get the
gameRules
?
r
yes
Copy code
rules(parent, {where}, ctx, info) {
    const {id} = isLoggedIn(ctx)
    return ctx.db.query.rules({where: {author: {id: id}}}, info)
  },
this produces the exact same results as the above snippet
I was trying to figure out how to do that without using the current user’s id in the client query
w
In that case, think of it more like a permission check:
Copy code
rules(parent, args, ctx, info) {
    const isAuthor = isAuthorCheck(ctx)
    return isAuthor ? ctx.db.query.rules({}, info) : null
  },
r
I see what you’re saying
but I don’t think that works in my case
what is
isAuthorCheck
actually checking? the Game itself doesn’t have an author
w
what rule do you want to enforce?
r
its hard to explain, but I think I’ll just have to create a separate query
a user should be able to query for just rules they’ve created for a game
but also query for rules everyone else has made
I guess I’ll just make a
currentUserRules
query and a
publicRulesQuery
or something like that
w
In that case, can't they access all the rules, and do the querying on the client side? why the need to restrict them?
or have separate queries?
r
okay, so using the current user’s id in the client query….
the only place the current user’s id is stored is in apollo’s cache
w
if the userId is only client side, then they can use it in their query to search for their own rules
r
also, if you’re on the game view and refresh, the
me
query actually isn’t run so the current user id isn’t even in cache yet
so, I’d have to for the me query to be run first on any page, then get the result and use the id to make another query to get their games
and my thought was, well, I’m passing in a token to the server that contains the id so I could just use that instead
w
if you setup a relation between User and Games/Rules, then you could get their rules as part of the initial me query