Closed
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?
Metadata
Metadata
Assignees
Labels
No labels