-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GraphQLInterfaceType Fields conflict because they return conflicting types #522
Comments
I don't have an opinion on the underlying issue, but you can work around this limitation by using an alias in the query. |
Thanks @stubailo. Aliases proved to be a valid workaround, although they did add some complexities to our tests. For those playing at home, the alias is added to the query as follows:
|
The safe divergence case was fixed long ago, so unless you're using a very old version of graphql-js, then that case is being accounted for! Looking at this example, I would not expect this to be a safe divergence though. Perhaps it doesn't matter for your particular environment if you're using dynamically typed languages, but if you were using a statically typed language, then you would have encountered a problem when trying to correctly type the result of In this case you have two options:
|
@leebyron There seems to be slight inconsistency. I believe these test cases are up to the spec: But I can't wrap my head around how the argument about strongly typed languages doesn't apply to object types. How is that different from enums? Obviously, I would like the case with enums to also be safe. 😇 I know I'm very late to the party but thank you very much for any explanation. |
@brabeji Query results are strongly typed based on possible field values: TL;DR; Only field values are conflicting with each other. In your test case: ... on Character {
name
}
... on Human {
rankObject { __typename name }
}
... on Droid {
rankObject { __typename name }
} You can think as it stong-typed with following unnamed type:
In you enum test case you can think as it stong-typed with:
|
Btw I've just found that a very nice explanation is given in the reference code itself:
and
thank you @IvanGoncharov ! |
I have a scenario where multiple entities implement a common interface with the shared field "type", but each entity also has an attribute "recurOn", where MonthlyRecurrence.recurOn is a different set of enum values to FortnightlyRecurrence.recurOn. Currently if I try to query on this attribute I get the error Fields "recurOn" conflict because they return conflicting types.
I read through the thread here: #53 which is more specifically regarding types with differing arguments, and to me my scenario falls into the category of "safe divergence" which should be allowed for. Since the field is defined within each child entity I would think there's no opportunity for ambiguity. Do you think it would be safe to allow this scenario?
The text was updated successfully, but these errors were encountered: