feat: added graphql.UnmarshalInputFromContext #2131
Conversation
Co-authored-by: Ariel Mashraki <7413593+a8m@users.noreply.github.com>
| maps := make(map[reflect.Type]reflect.Value) | ||
| for _, v := range unmarshaler { | ||
| ft := reflect.TypeOf(v) | ||
| if ft.Kind() != reflect.Func { | ||
| panic("unmarshaler must be a function") | ||
| if ft.Kind() == reflect.Func { |
There was a problem hiding this comment.
I prefer this avoiding of panics, but if the kind is not a function... what now happens when nothing is added to the maps here?
|
This function can lead to another issue, that is resolver/directives can be executed twice times during query phrase. The first time by |
What is the symptom of this and how can we work around this problem? |
Co-authored-by: Ariel Mashraki <7413593+a8m@users.noreply.github.com>
For example, the below directive will be called twice times. But I think it won't have any critical effects (because the most directive are stateless). And only called twice time when using gqlgen with entgql. input TodoInput {
blahBlah: String! @directiveCount
} |
@StevenACoffman, currently, ent executes the unmarshaling "ahead of time" and resolves all fields (in all levels) in the root query. However, gqlgen runtime does not know that and calls all fields' resolvers even though they were resolved - ent returns the cached result in this case. We plan to send additional patches to skip this and improve performance for ent users. |
|
Ok, I can merge this now, but I would ask for a fast follow with patches to have gqlgen runtime skip the redundant resolving so other users of this functionality do not have a problem that seems like it would be very hard to see the cause of. For example, I can imagine someone who wanted to build a GraphQL federatation gateway using gqlgen using this same functionality with non-idempotent directives. |
This allows unmarshaling the input object from a context.
This PR is the support for ent/contrib#297: entgql: Unmarshal whereInput using graphql package
I have: