You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to go ahead and present this RFC for implementation, possibly early as it looks to have full support. Or, at the least, I'd like to get the discussion and ideas flowing for implementation in the future.
This is particularly of interest in cases where you have an update mutation that has optional relational inputs. In this case, you have to support creating and updating for the relation. It's also the case for one:many relationships, if you wish to update relations within a parent mutation.
There are a number of other use cases that are also important. The above use case is one that we're finding to be very common and a continual frustration point with the API/schema.
The text was updated successfully, but these errors were encountered:
GraphQLite uses webonyx/graphql-php under the hood for schema generation and GraphQL parsing.
I'm all in favor of implementing polymorphic input types but we need first to have it supported by webonyx/graphql-php. So I think you should first open an issue with them.
Once it is supported in webonyx/graphql-php, it to GraphQLite should be quite easy.
Been 4 years since this was posted so I'd be keen to see if there's any updates to this ? Been a good point of frustration for me aswell. Currently trying to make some form of workaround using a custom RootTypeMapper.
I'd like to go ahead and present this RFC for implementation, possibly early as it looks to have full support. Or, at the least, I'd like to get the discussion and ideas flowing for implementation in the future.
https://github.com/graphql/graphql-spec/blob/master/rfcs/InputUnion.md
This is particularly of interest in cases where you have an update mutation that has optional relational inputs. In this case, you have to support creating and updating for the relation. It's also the case for one:many relationships, if you wish to update relations within a parent mutation.
There are a number of other use cases that are also important. The above use case is one that we're finding to be very common and a continual frustration point with the API/schema.
The text was updated successfully, but these errors were encountered: