SchemaParserDictionary does not accept different types mapping to the same Java class

[asfernandes]

I'm trying in so many ways to create a schema that is partically created by static Java code (with spring-boot-graphql) and partially created dynamically, reading a file and generating the schema and the resolvers.

Every way I try I enconter some show stopper.

One big one is that I need to add the dynamic types to SchemaParserDictionary mapping then to Map.class. When I have only one type my schema is fine. But when I try to add a second type it does not accept because SchemaParserDictionary uses a BiMap.

Why more than one type cannot be mapped to Map in the dictionary. How to use more than one dynamic type?

[asfernandes]

It worth noting that schema, where Test, Test0 and Test01 are dynamic types.

Test does not need to be in the dictionary. Why?

Test0 and Test01 is not allowed to be in the dictionary mapping to Map.class. Why?

extend type Query {
	test: Test @mydirective
}

type Test {
	id: String
	name: String
	test0: Test0 @mydirective
}

type Test0 {
	x: String
	test01: Test01 @mydirective
}

type Test01 {
	y: String
}

[oliemansm]

The whole idea of this lib is that it matches an SDL to a class hierarchy. It does support Map<String,Object> representation, but not to represent an entire hierarchy. If you look at the test cases for supporting Maps with nested types it does not allow you to do something like Map<String,Map<String,Map<String,Object>>> but instead expects the value of the Map to be of a type that can be found, e.g. Map<String,Test>.

You'd be better of using graphql-java directly in this case to construct your schema and to wire the data fetchers. I don't know how large your static schema is that can be constructed using graphql-java-tools. You might be better off using graphql-java directly instead of using this lib, since then at least you have full control of these kind of things.

Schema stitching or Federation which seems to be its replacement is not supported at this time as you've seen in #134, and don't foresee this being added anytime soon either unfortunately due to time constraints.