smallrye-graphql
smallrye-graphql copied to clipboard
smallrye
Add support for `@Ignore(on=Type)` or `@Ignore(on=Input)`
If a java class is used an Input as well as a Type, but there are resolver methods in the GraphQL service, then some fields are returned as output but not allowed as input (see also #517). Instead of defining two separate classes with most of the fields duplicated, it would be convenient to mark some fields as @NonInput, so the typesafe client checks that they are actually null and then doesn't send them at all to the service.
What about using @Ignore ? Use it on the setter to ignore the input and on the getter to ignore the output. Does that not do what you want ? (That is how the server works)
Oh, yeah. I forgot about that one. Maybe @NonInput would still be more explicit? WDYT?
The trick with @Ignore isn't supported in the client. I could add that, but this would require explanation/learning. It's not obvious that ignoring a setter means it's not passed as an input.
But @OutputOnly is probably better than @NonInput, isn't it?
Yea I would still keep the server and client the same. Json works the same way, so it's not brand new logic.
The client still has its own logic to recognize and handle fields. It would be a major change to use the code from the common module. I assume that this is a natural thing to do when switching to the dynamic client after it's finished.
We need to do what we want to see in the spec, and I believe that would be to sync the client and server. @andymc12 what do you think ?
I totally agree that we'll have to do much more before it's ready to be lifted into the spec.
This would be a change to the spec, as the @Ignore annotation is from the spec.
The suggestion to put @Ignore on the getter or setter only would require that the typesafe client even considers getters and setters.
A first fix for some cases would be to consider the @Ignore for the fields getting into the request.