[jira] [Updated] (SLING-9796) Add support for using Unions

["Radu Cotescu (Jira)" <ji...@apache.org>]

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

Radu Cotescu updated SLING-9796:
--------------------------------
    Summary: Add support for using Unions  (was: GraphQL add support for using Unions)

> 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
>    Affects Versions: GraphQL Core 0.0.8
>            Reporter: Adrian Kozma
>            Priority: Major
>
> (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)