Validation directives on nested Input fields example

[PhilippS93]

Hello,

Thank you for your work on this library. This is very helpful.

I want to use a directive to validate input fields like so:

input UserInput {
name: String @SiZe( min : 2, max : 255)
}

There is a callback in SchemaDirectiveWiring:

default GraphQLInputObjectField onInputObjectField(SchemaDirectiveWiringEnvironment<GraphQLInputObjectField> environment) {
        return environment.getElement();
    }

but there is no example on how to use this method to validate the input. There are only examples for onArgument and onField callbacks.

Is it possible to provide examples for this kind of validation?

Thanks

[oliemansm]

Hi,

I would think implementation of the onInputObjectField callback would be similar to the samples of onArgument and onField. Isn't it possible to deduce it from those samples?

[PhilippS93]

Hi @oliemansm . I have tried to use the onField example but I am getting the error:
Caused by: graphql.AssertException: An output field must be in context to call this method on calling

DataFetcher originalFetcher = environment.getFieldDataFetcher();

[brendamckenne]

did you get this resolved anyhow? @PhilippS93

[mohammali]

Any update?

[PhilippS93]

@sumitbadaya27 , no the provided examples are unfortunately not working. @oliemansm , any ideas?

[brendamckenne]

Yeah not working for me too. We are using kickstart with java extended validations library. The library works but then resolvers dont. And if resolvers work then validation wont.

…

On Sat, 4 Apr, 2020, 5:14 PM Philipp Staudt, ***@***.***> wrote: @sumitbadaya27 <https://github.com/sumitbadaya27> , no the provided examples are unfortunately not working. @oliemansm <https://github.com/oliemansm> , any ideas? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/graphql-java-kickstart/graphql-spring-boot/issues/341#issuecomment-609016064>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL37CYNWB2EZLBPYRM6IBLLRK4MRDANCNFSM4KT3JFZA> .

[oliemansm]

I’ll try to take a look at it this weekend.

[brendamckenne]

Thanks
In case you'd need the link of library for validations, Its here:
https://github.com/graphql-java/graphql-java-extended-validation

[oliemansm]

@sumitbadaya27 You're issue seems to be different than what @PhilippS93 raised. You're not getting the validators from that library to work with this project apparently. I don't know how you configured it, but they don't provide a starter but just a library. So you have to expose their SchemaDirectiveWiring into a SchemaDirective bean to be actually configured.

@PhilippS93 graphql-java hasn't documented this either and they refer to https://github.com/graphql-java/graphql-java-extended-validation for example implementation. It uses a FieldDefinition and walks the arguments and input types based on that. I'll see if I can get something like that to work in the sample.

[brendamckenne]

@oliemansm Is there any way through in your library in which we can pass typeDefinitionRegistry and runtimeWiring in generating schema in schemaParser builder?
basically this thing: GraphQLSchema graphQLSchema = new SchemaGenerator().makeExecutableSchema(typeDefinitionRegistry, runtimeWiring);

Also, I configured it correctly as I am getting proper validation message but its just that I am not able to add resolvers and my resolvers fail to work if Validation works.

[oliemansm]

@sumitbadaya27 Create a separate issue for that please, this particular issue is not about that library or these questions.

[brendamckenne]

okay

[oliemansm]

The problem is that graphql-java-tools wires the directive on objects and its fields without passing along the constructed GraphQLInputObjectType. That's what is preventing that extended-validation library to fail too. Because it does an instanceof check in case the argument is a GraphQLInputObjectType, while in fact at that point because of the logic in graphql-java-tools, it is a GraphQLTypeReference.

By making some quick changes in graphql-java-tools I was able to pass it along and got it working. Needs a bit more work and clean-up though.

[brendamckenne]

Till the time you cleanup the code, Can you please provide the code that you tweaked ans tried and the location where i need to put that code? So that my work also doesnt stop at this as i am blocked coz of this

…

On Sun, 5 Apr, 2020, 1:18 AM Michiel Oliemans, ***@***.***> wrote: The problem is that graphql-java-tools wires the directive on objects and its fields without passing along the constructed GraphQLInputObjectType. That's what is preventing that extended-validation library to fail too. Because it does an instanceof check <https://github.com/graphql-java/graphql-java-extended-validation/blob/bef87f7cbfd6d970aba413eaa51c57852470f77f/src/main/java/graphql/validation/util/DirectivesAndTypeWalker.java#L31> in case the argument is a GraphQLInputObjectType, while in fact at that point because of the logic in graphql-java-tools, it is a GraphQLTypeReference. By making some quick changes in graphql-java-tools I was able to pass it along and got it working. Needs a bit more work and clean-up though. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/graphql-java-kickstart/graphql-spring-boot/issues/341#issuecomment-609080224>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AL37CYLOJJFMOXTJH24FABDRK6FKNANCNFSM4KT3JFZA> .

[oliemansm]

I'll push a snapshot release of graphql-java-tools when it's ready to do so and push the updated samples containing the example code then too.

You can do validation on the resolvers themselves in the meantime. That's a valid workaround available to you, so you're actually not blocked by this.