Skip to content
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

Avoid need for wrapper around single argument GraphQL input types with Querydsl and Query By Example #216

Closed
rstoyanchev opened this issue Dec 9, 2021 · 1 comment
Assignees
Labels
in: data Issues related to working with data type: enhancement A general enhancement
Milestone

Comments

@rstoyanchev
Copy link
Contributor

Currently, QueryByExampleDataFetcher creates the example Object from the full arguments map. For queries with a single argument that is a GraphQL input type, this means the example object isn't the direct equivalent of the GraphQL input type, but rather a wrapper around it with the GraphQL input type as its only field.

We can improve this by detecting that a query has a single argument that is a GraphQL input type, and have the QueryByExampleDataFetcher use that argument as its source rather than the full arguments map.

The same applies to QuerydslDataFetcher, which builds a predicate relative to the full map, but for such single argument queries, it might make more sense to nest and be relative to that argument.

@rstoyanchev rstoyanchev added type: enhancement A general enhancement in: data Issues related to working with data labels Dec 9, 2021
@rstoyanchev rstoyanchev modified the milestones: 1.0.0-M4, 1.0.0-M5 Dec 9, 2021
@rstoyanchev rstoyanchev modified the milestones: 1.0.0-M5, 1.0 Backlog Jan 6, 2022
@rstoyanchev rstoyanchev modified the milestones: 1.2 Backlog, 1.2.0-M1 Jan 12, 2023
@rstoyanchev rstoyanchev changed the title Improve Query By Example and Querydsl support for single argument queries with GraphQL input type Avoid need for wrapper around single argument GraphQL input types with Querydsl and Query By Example Jan 12, 2023
@rstoyanchev
Copy link
Contributor Author

It looks like we may be able to look this up at runtime via getFieldDefinition().getArguments() on DataFetchingEnvironment, which would work transparently for both auto-registered and manually registered DataFetcher repositories.

If that doesn't work, we could try getFieldDefinition().getInputValueDefinitions() on FieldWiringEnvironment from the WiringFactory in AutoRegistrationRuntimeWiringConfigurer, but that would only cover auto-registrations. For manually registered ones, one would have to provide the argument name.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues related to working with data type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

1 participant