Skip to content
This repository has been archived by the owner on Jul 8, 2023. It is now read-only.

Multiple mutations with the same name #128

Open
edomora97 opened this issue Oct 5, 2022 · 1 comment
Open

Multiple mutations with the same name #128

edomora97 opened this issue Oct 5, 2022 · 1 comment
Labels
enhancement New feature or request question Further information is requested

Comments

@edomora97
Copy link
Contributor

Is it possible to have multiple mutations with the same name, under different parent types?

For example:

@gql.type
class Namespace1:
    @gql.django.mutation
    def mut(self) -> Res1:
        return Res1(1)

@gql.type
class Namespace2:
    @gql.django.mutation
    def mut(self) -> Res2:
        return Res2(2)

@gql.type
class Mutation:
    ns1: Namespace1
    ns2: Namespace2

used as:

mutation Mutation {
  ns1 {
    mut {
      __typename
      ... on Res1 {
        res1
      }
    }
  }
}

This was working fine until I've tried to switch from gql.mutation to gql.django.mutation to use OperationType for handling the errors. The problem is that the two mutations, even though they return different types according to the type annotations, in the generated graphql they share the same union (MutPayload) which is the payload of one of the two. Therefore, for one mutation it works fine, while the other has a broken schema.

Is this supported? Are there plans to support it? Am I missing some docs regarding it?

The project I'm working on has many mutations, and we'd like to keep them grouped. Sure, we can rename them to have unique names, but it feels kinda odd (especially since there is no warning or error message about the duplicates).

Thanks!

@bellini666
Copy link
Member

Hi @edomora97 ,

That's an interesting use case, it is the first time I saw someone doing mutations inside a type =P

This is a corner case I have not handled because mutations are usually directly inside the root Mutation, and thus it would not be possible for them to have duplicated names.

What can probably be done here is to add an optional parameter with a payload name that should be used instead of the automatically generated one. What do you think?

@bellini666 bellini666 added enhancement New feature or request question Further information is requested labels Oct 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants