Support for PropertyDataFetcher behavior

[nickweedon]

When using graphql-java alone and taking the approach of writing DataFetchers, the framework will allow you to return a Map object that contains the property names and values for the corresponding GraphQL type and the framework will then map this to the appropriate GraphQL type using the PropertyDataFetcher (as described in https://graphql-java.readthedocs.io/en/latest/schema.html under DataFetcher and TypeResolver).

It seems that this same behavior is not supported when using graphql-java-tools with the GraphQLResolver approach.

Here is an example:

public class Book {

    private int id;
    private String name;
    private int authorId;

    // constructor and getters/setters ...
}

public class BookResolver implements GraphQLResolver<Book> {

    public Map author(Book book) {

        return Collections.unmodifiableMap(new HashMap<String, Object>() {
            {
                put("id", "1");
                put("name", "smith");
            }
        });
    }
}

The GraphQL schema file is:

type Query {
    books: [Book!]
}

type Book {
    id: Int!
    name: String!
    author: Author!
}

type Author {
    id: Int!
    name: String!
}

When I attempt to build this schema, I get the following exception:

com.coxautodev.graphql.tools.FieldResolverError: No method or field found with any of the following signatures (with or without graphql.schema.DataFetchingEnvironment as the last argument), in priority order:

java.util.Map.id()
java.util.Map.getId()
java.util.Map.id

I also tried changing the return type to Map but then I get this:

com.coxautodev.graphql.tools.TypeClassMatcher$RawClassRequiredForGraphQLMappingException: Type java.util.Map cannot be mapped to a GraphQL type! Since GraphQL-Java deals with erased types at runtime, only non-parameterized classes can represent a GraphQL type. This allows for reverse-lookup by java class in interfaces and union types.

My expectation in this case would be that the map would be resolved to the correct type in the same way that the PropertyDataFetcher used to work. I actually found this to be an extremely valuable feature since it meant that I did not require a POJO for every GraphQL schema type.

I am happy to try to contribute to fixing this issue via PR but I first wanted to check that this is indeed a bug and that I am not missing something here such as another means of achieving this?

[Purus]

Same issue. any help ?

[oliemansm]

There seems to be enough support for fixing this, so if your offer of creating a PR still stands, it would be much appreciated.

[nickweedon]

Certainly, I will get started this week.

[deepd]

It would also be great to assign a default function that can be used in PropertyDataFetcher to apply every time there's no POJO for a GraphQL schema type.
Ref: PropertyDataFetcher(Function<O, T> function)

[nickweedon]

Just an update on my progress...
I have forked the project with the branch "Issue-113-Support-PropertyDataFetcher" which I will soon submit as a PR once I have added some more tests and performed some code cleanup.
So far so good and the main use case is working (including unit tests) along with a more complicated use case where the schema type that is backed by a map contains 'complex' types.

The interesting thing here is that the later use case turns out to be non-trivial as far as the implementation is concerned. The difficulty stems from the way in which the schema type <=> POJO type mapping is derived. For the existing (before my changes) implementation there is the pre-requisite condition that all POJO types must be reachable from one of the 'Query' or 'Mutation' starting points. This is because the code relies on this as a way of discovering these types while traversing the graph.

With that being said, the problem in relation to introducing a property map is this:
A map of type Map<String, Object> (property name => property value) will create a disjoint graph w.r.t. POJO types since the underlying POJO type of each member of the map (i.e. each property) is not ascertainable via reflection until runtime.
In order to work around this I have also introduced a new type of GraphQLResolver called GraphQLTypeNameResolver which facilitates a mapping between a schema type and POJO thereby allowing the disjoint section of the graph to be discoverable.
Below is an example of such a resolver (in Kotlin):

class ComplexMapItemResolver : GraphQLTypeNameResolver<ComplexMapItem> {
    override fun getTargetType(): String {
        return "ComplexMapItem"
    }
}

This maps the schema type "ComplexMapItem" to the POJO type "ComplexMapItem".

I was hoping for a more 'user friendly' solution to this problem but I can't see this being solved in any way that requires less configuration other than to introduce annotations on said POJOs and use reflection to scan for these components. This seems very excessive however for this small edge case.
There was also one other potential solution that came to mind which is to create a normal resolver for the schema type where the map is being used and just provide resolver property implementations for the complex types and leave the scalars to be worked out automatically. This is nice in the sense that a Schema <=> POJO mapping resolver is then not needed however the downside is the use case where there are several different schema objects using maps that all share the one POJO as a map property as this then leads to repetitive code.
Overall I am happy so far with the solution I have chosen but it will of course need to be followed up with additional documentation for this 'advanced usage' scenario.

[nickweedon]

@deepd I like your idea and I will open another issue to cover this after this issue is merged since I want to try to reduce the scope of this change as much as possible. I have an idea on how to implement this and I will mention this in the new issue. Feel free to create the issue yourself and link it here, otherwise I will create one myself in due course.

[oliemansm]

@nickweedon Sounds good!