Add DataFetchingEnvironment parameter to main query resolver

[joffrey-bion]

Is your feature request related to a problem? Please describe.
When using GraphQL Java Tools, the main Query resolver, like other resolvers, can take an optional DataFetchingEnvironment parameter.
It is currently generated in all resolvers interfaces, but not for the root resolvers like Query.

Describe the solution you'd like
It'd be nice to provide this DataFetchingEnvironment argument to the query resolver's methods.
If we need backwards compatibility, we could use a config parameter to add or not the DataFetchingEnvironment argument in the generated interfaces.

Describe alternatives you've considered
There is no other way currently than to stop implementing the Query interface, which is a pain because changes to the schema don't make the compilation fail.

[kobylynskyi]

Good idea.
I think we definitely need a configuration parameter for this (which will default to ‘false’)

[joffrey-bion]

Should this param also affect field resolvers?

…

On Wed, Apr 8, 2020, 20:30 Bogdan Kobylynskyi ***@***.***> wrote: Good idea. I think we definitely need a configuration parameter for this (which will default to ‘false’) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOTDUHL6XAM4GWLSIALIY3RLS7GDANCNFSM4MEEEM3Q> .

[kobylynskyi]

Yes, agree.

[joffrey-bion]

I tried to look into this one, but I realized that there is some duplication around operations VS field resolvers. They are currently treated differently, but the root Query object is just a special case of type that only needs a resolver and no POJO.

Technically OperationDefinition could be the same thing as FieldResolverDefinition (and thus would automatically solve the current issue). Would you like me to make this unification? Or do you prefer to keep changes to a minimum and maybe unify later as a separate effort?

[kobylynskyi]

Yes, we could definitely make the unification. Thanks for finding this.
But how will this automatically solve the issue?

[joffrey-bion]

By automatically I meant that if the code is not duplicated, adding the DataFetchingEnvironment in one place solves the other one.

…

On Thu, Apr 9, 2020, 17:27 Bogdan Kobylynskyi ***@***.***> wrote: Yes, we could definitely make the unification. Thanks for finding this. But how will this automatically solve the issue? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#61 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOTDUBTEGS355D2JUHUO7TRLXSPLANCNFSM4MEEEM3Q> .

[kobylynskyi]

@joffrey-bion, will you be able to work on this feature? I would really appreciate it.
Otherwise, I can do it over the weekend.

[joffrey-bion]

Yes, I'll try to work on it tomorrow