I run into the following issue/question while evaluating the capabilities of the new neo4j/graphql.
When I setup my graphql model as follows and wanna query some relationships with specific ns0__hasSortKey value, I dont seem to be offered with the proper syntax by the Graphiql. If I use unions without properties attribute at the relationship directive, the retrieval works fine and no filtering capabilities (as expected).
>>>>>>>>>snippet of model starts >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
type ns1__Work @exclude(operations: [CREATE, UPDATE, DELETE]){
ns0__relatesToChild: [relatesToChildTarget] @relationship(type: "ns0__relatesToChild", properties: "ns0__CHORelateProps" ,direction: OUT)
ns0__relatesToParent: [relatesToParentTarget] @relationship(type: "ns0__relatesToParent", properties: "ns0__CHORelateProps" ,direction: OUT)
}
interface ns0__CHORelateProps{
ns0__hasSortKey: String!
dct__isPartOf: String
dct__type: String
}
union relatesToChildTarget = ns1__Expression | ns1__Work | ns0__WorkCollection
union relatesToParentTarget = ns1__Work | ns0__WorkCollection
<<<<<<<<<<<<<<<<<<<Snippet of model ends<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Conceptually, we treat unions as something of a "collection of not necessarily related entities". As such, when filtering them, we divide them up into their member types as early as possible.
As such, I believe the syntax for your query should be:
I'm not 100% on that, and I don't have your full type definitions to verify, but can you give it a go and report back?
Looking at this now I realise that "the split" shouldn't happen until the node level, but this is what we will be doing when we introduce interfaces, and I think this is the important thing that divides the two. This has certainly given me some food for thought!