Replace use of DataBinder for binding GraphQL arguments #516
Comments
This was referenced Oct 19, 2022
rstoyanchev
added a commit
that referenced
this issue
Oct 20, 2022
DataBinder is not a great fit to bind GraphQL arguments which are essentially a (structured) map of maps and collections, rather than a (flat) map of property values with JavaBean paths. We already navigate recursively the GraphQL arguments map, which corresponds to the target Object structure, creating values, so all we have to do is check for matching bean properties at each level and set them. See gh-516
koenpunt
pushed a commit
to koenpunt/spring-graphql
that referenced
this issue
Feb 2, 2023
DataBinder is not a great fit to bind GraphQL arguments which are essentially a (structured) map of maps and collections, rather than a (flat) map of property values with JavaBean paths. We already navigate recursively the GraphQL arguments map, which corresponds to the target Object structure, creating values, so all we have to do is check for matching bean properties at each level and set them. See spring-projectsgh-516
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
GraphQlArgumentBinderhas supports populating a nested object structure, as long as target objects use constructor injection. For objects with a default constructor, and getters/setters, we useDataBinder. This has led to cases where we can fix an issue for constructor injection, where we have target type info handy, but can't do the same with theDataBinder, see #447 (comment) and #449 (comment). There are also other issues that are more challenging to address like #140 (comment) with this approach.We already have the ability to bind a raw value from the argument map, also by nesting as needed, and should be able to scale back the use of
DataBinderand only use aBeanWrapperto inspect a target property as well as to set it.The text was updated successfully, but these errors were encountered: