Open dwwoelfel opened 5 years ago
Sorry for the slow response. I have two ideas for how to solve this:
Graphql_parser.field
passed to the resolver (via resolve_info.field
).null
is passed. This would result in a type like [`Null | `Not_null of string] option Schema.Arg.arg_typ
, where None
means not present and Some `Null
means null
was passed (you don't have to use polymorphic variants, I just used it here for simplicity).The second approach is a bit of a hack to implement outside of the library though. I haven't thought it through, but maybe it should be a native feature of OGS.
I'm not very familiar with the GraphQL spec, but this discussion could be relevant: https://github.com/baransu/graphql_ppx_re/issues/26#issuecomment-542182296
If this is correct, the current behavior of raising an error when nullable variables are missing from the variables dictionary does not align with the spec.
I'm not very familiar with the GraphQL spec, but this discussion could be relevant: baransu/graphql_ppx_re#26 (comment)
If this is correct, the current behavior of raising an error when nullable variables are missing from the variables dictionary does not align with the spec.
Can you elaborate on what you mean by this? And feel free to open a separate issue -- at first glance it does not appear related to this issue (though I could be mistaken) 😄
@andreas It's more of a question I guess, I don't know what behavior is correct and I'm curious whether a possible OGS solution to this issue would be relevant to my issue.
query getUsers($first: Int, $after: Cursor) {
users(first: $first, after: $after) {
nodes {
id
}
}
}
If I call this query with { "first": 10 }
I get this error back:
{
"errors": [
{
"message": "Missing variable `after`"
}
],
"data": null
}
while { "first": 10, "after": null }
works.
In fact, this was the way graphql_ppx
worked. It would force me to declare every variable and construct something like { "first": Some(10), "after": None }
, and it would encode None
with null
.
After switching to graphql_ppx_re
because of newer BuckleScript support I noticed my null
(None
) values started to get dropped, which ocaml-graphql-server did not like.
During the subsequent discussion in the issue the author said he made this change to work around an issue with Sangria, but also that this change is compliant with the spec.
Now I realize that my issue is about variables passed to the query, which is not this issue is about. But I'm still curious about your opinion on this, is this something I should attempt to solve on the client side, or at ocaml-graphql-server side?
Is there some way to distinguish between the user passing in null and the user passing in nothing for an arg?
I have a use case for an update mutation that requires me to distinguish between missing and null. If the value was provided as null, then the underlying field in storage needs to be nulled out, but if the value is missing, then the underlying field should remain unchanged.
Example: