Repository navigation
Supporting multiple Union types in one schema #84
Description
Currently having two different Union types in a single schema seems to be impossible if both have to be represented as java.lang.Object in the resolver return signature (which I imagine is a pretty common case for unions).
I've created a PR to illustrate this issue, extending the end-to-end schema test with a second union, causing it to fail: #83
Am I missing something stupid here? If not, there seem to be some fairly straightforward ways to fix this, but I don't know which way is better.
One simple solution would be to leave unions out of the type<->class bimap altogether, as you would generally only need a typeresolver for the types within the union, not the union itself (except in case of nested unions).
Thoughts?
Activity
filipncs commentedon Oct 19, 2017
I added another commit to the PR, with one possible way of resolving the issue, by handling unions and their possible types separately. This also supports nested unions.
Apologies for what I imagine is clumsy code. I'm new to Kotlin.
The explicit test for handling of nested unions is on the flimsy side, due to the fact that the test data is mutated by other tests. I left it as-is for now, but this might also be worth cleaning up.
apottere commentedon Nov 23, 2017
Thanks for the PR! I'll be releasing this soon.