Allow @hasInverse on union types

Issues GraphQL
,
4

It is not about the validity of the schema, but promoting a better schema design. Dgraph could surely check the one-off special case of all the member types in a union having a common field. But, that is the exact reason why GrpahQL has interfaces. That is what interfaces are supposed to do. That is what it has always been with GraphQL: a better schema design to begin with. We have had discussions about this particular issue internally previously as well, and we decided not to allow hasInverse with unions because of the same reasons.

The intention of Unions is to be able to represent particular instances of different types, not all the instances of them in general. @michaelcompton has explained this tiny bit of difference here brilliantly:

You should be using an interface in this case, like this:

type Foo {
   m: [Hello!]! @hasInverse(field: foo)
}

interface Hello {
   id: ID!
   foo: Foo!
}

type Blub implements Hello {
   ...
}

type Blabla implements Hello {
   ...
}

and not a union.

For this particular case, you can always update Foo to add more children.

I believe the code generator that you are using, although it uses a type to represent interface in typescript, it is up to you to use it. You can choose to not create its instances, and anyways, if the GraphQL server you are interacting with doesn’t allow creating interfaces, you will eventually get an error from there if you do a mutation to create an interface. I understand that it feels weird creating instances of an interface on the client-side, but if the code generator is using type to represent interface, then either there is a reason behind it or that is something that can be improved there.

[EDIT]: We could surely re-discuss it again, and see if we should allow hasInverse on Unions, but it doesn’t make a semantic sense, is what has been the reason behind not allowing it yet after all.

1 Like