Using the same type for querying and mutation
See original GitHub issueToday I learned that to allow a custom type as mutation argument, it needs to inherit from InputObjectType
and it’s fields need to be of InputField
type.
I think this requirement is forcing duplicating of types. What I mean is, say I have a Person
type as:
class Person(ObjectType):
id = Int()
first_name = String()
last_name = String()
address = Field(SomeOtherType)
I expose it as a query-able object as well as return it as a result.
Now, If I want to allow it as a mutation argument to update a Person’s details, I will have to redefine it as something else:
class Person_1(InputObjectType):
id = Int()
first_name = String()
last_name = String()
address = InputField(SomeOtherType)
If this is the only way to do this, I think it is forcing me to define near duplicate types. Is there a way to work around this?
Can something be done about this in the code so that we can use the same type definition for querying as well as a mutation argument?
Issue Analytics
- State:
- Created 8 years ago
- Comments:14 (4 by maintainers)
Top Results From Across the Web
GraphQL Mutation vs Query – When to use a GraphQL Mutation
In GraphQL, there are only two types of operations you can perform: queries and mutations. While we use queries to fetch data, we...
Read more >Queries and Mutations - GraphQL
Multiple fields in mutations A mutation can contain multiple fields, just like a query. There's one important distinction between queries and mutations, other ......
Read more >GraphQL: How to reuse same type for query and mutation?
It need to use "input type". I know that in this example, it is not really complicated to do, but if user was...
Read more >Input object type as an argument for GraphQL mutations and ...
With this knowledge we can now dive deeper into the world of GraphQL input types. GraphQL is a query language, which can be...
Read more >Graphql Queries and Mutations - DataDrivenInvestor
One factual difference between a query and a mutation is at any rate structurally. · That difference is the operation type. · We...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Can you re-open this!! I agree that an AbstractType or similar needs to be able to be used to define both an Object and an InputObject. Noting that the AbstractType is now deprectaed at the least this should be possible from an Interface
Hello @syrusakbary, this really works for single level fields. Please, how do I nest one inside another?
Let’s say I have:
How do I fit they together?