[ 
https://issues.apache.org/jira/browse/SLING-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Radu Cotescu reassigned SLING-9796:
-----------------------------------

    Assignee: Radu Cotescu

> Add support for using Unions
> ----------------------------
>
>                 Key: SLING-9796
>                 URL: https://issues.apache.org/jira/browse/SLING-9796
>             Project: Sling
>          Issue Type: New Feature
>          Components: GraphQL
>            Reporter: Adrian Kozma
>            Assignee: Radu Cotescu
>            Priority: Major
>             Fix For: GraphQL Core 0.0.8
>
>
> (i) The current implementation of *sling-org-apache-sling-graphql-core* is 
> not supporting the *Union* type, however there's a way to implement it.
>  1. Hardcoded solution just to prove what is missing.
> Supporting *Unions* can be added by extending the *buildWiring()* method [3] 
> adding the following lines  
>  - based on the graphql-java documentation [4] the TypeResolver returns the 
> schema ObjectType based on the current result item instance
> {code:java}
>         List<UnionTypeDefinition> unionTypes = 
> typeRegistry.getTypes(UnionTypeDefinition.class);
>         for (UnionTypeDefinition type : unionTypes) {
>             TypeResolver typeResolver = env -> {
>                 Object javaObject = env.getObject();
>                  // schema contains only one union definition:
>                  //     "union TestUnion = Type_1 | Type_2 | Type_3 | Type_4"
>                  // hardcoding to force return the object type Type1
>                  return env.getSchema().getObjectType("Type1");
>             };
>             builder.type(type.getName(), typeWriting -> 
> typeWriting.typeResolver(typeResolver));
>         }
> {code}
>  2. General solution
> The suggested solution would be to extend 
> *sling-org-apache-sling-graphql-core* to allow TypeProviders as external 
> callable, following the pattern how it was implemented in case of data 
> fetchers.
> Unfortunately, there's no general logic (in sling) regarding how a 
> TypeProvider can decide which Object Type needs to be returned. The condition 
> is based on the result item (javaObject) which is constructed by the data 
> fetcher (external callable). Therefore, to match the logic, the TypeResolver 
> should be callable (OSGI component) which could be detected by directives 
> (@fecher) used by the Union type definition as follows:
> {code:java}
> # This directive maps the corresponding type resolver to a given Union
> directive @resolver(
>     name: String, 
>     options: String = "", 
>     source: String = ""
> ) on UNION
> union TestUnion @resolver(name : "test/resolver", source : "TestUnion") = 
> Type_1 | Type_2 | Type_3 | Type_4{code}
> [3] 
> [https://github.com/apache/sling-org-apache-sling-graphql-core/blob/19bc07c039bfb3e9d578e9c592b60c3da6bdd951/src/main/java/org/apache/sling/graphql/core/engine/GraphQLResourceQuery.java#L133]
>  [4] 
> [https://www.graphql-java.com/documentation/v11/schema/#datafetcher-and-typeresolver]
>   
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to