-
Notifications
You must be signed in to change notification settings - Fork 172
Best practices for handling optional arguments? #388
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
Comments
This was done so that it could be detected whether the client passed in a parameter or not. If you are not interested in the distinction, can you just use |
@vojtapol this is what we've started doing (updating the arguments to the unwrapped type, and doing an |
Another question... we already have a custom class that we use to differentiate null vs. absent called Edit: also want to mention that we have been using a custom deserializer for our omissible class on the schema object mapper for a while now, and it works for deserializing input object fields into omissibles, but we're seeing now that it doesn't work for top level field arguments. It seems like it should work the same for both? |
I think the right way to solve this would be to add a configuration option that changes how Optional behaves. The current behavior would be the default but you could switch it to the old behavior.
Can you show me how are you passing the custom deserializer? I don't need to see its implementation, just how it's provided to GraphQL Java Tools. |
👍 to this, we definitely don't want to have to null check top level arguments, when input sub-fields just work.
GraphQLSchema graphQLSchema = SchemaParser.newParser()
...
.options(SchemaParserOptions.newOptions()
.objectMapperConfigurer((mapper, context) -> {
mapper.registerModule(new OmissibleModule());
})
.build())
.build()
.makeExecutableSchema();
public class OmissibleModule extends SimpleModule {
public OmissibleModule() {
addDeserializer(Omissible.class, new OmissibleDeserializer());
}
} |
Any thoughts on this? This is basically blocking us from upgrading to the latest version |
#404 addresses the first half of this issue. Let me know if it would fix your issue.
This doesn't work because types that are a GraphQL scalars bypass the object mapper. We might want to look into changing that. |
@vojtapol any chance for a patch release in the near future? |
Yeah. There is a chance for that. We are planning to make the input argument mapping a lot more flexible for users that need more customization. |
We just updated graphql-java-tools from 5.4.1 and the biggest change is around nullable input fields (I think caused by #315).
Previously, we were defining our resolver methods with
Optional<>
arguments for those that are nullable in the schema, e.g.first
in... mapped to the following resolver method:
Previously, the
first
argument wasOptional.empty()
regardless of whether the client passed an explicitfirst: null
or didn't pass the argument at all. However, now we are gettingnull
when the client doesn't pass the argument, which requires us to handle bothnull
andOptional.empty
in all resolver methods with optional arguments.Is there a way to opt-out of this new behavior? Or if not, a recommended way to unify handling of
null
and absence? e.g. in the object mapper configurer or something?The text was updated successfully, but these errors were encountered: