Edge properties as parameters or where conditions

[jbhurruth]

We have a schema where many edges have the Boolean property verified which confirms that an edge has been verified by a human since we're dealing with noisy data and inferring relationships. We want to be able to state whether we want just verified edges or all edges in our query results. Right now that means for one scenario we can just ask for the node, but for the other we'd have to use the "nodeConnection" form which returns a very different nested structure.

We also have a few convenience properties that have custom cypher and return the same types, and these are trivial to add such functionality to using parameters. If we choose to the "nodeConnection" form to achieve what we want we'd either have an inconsistent API or we'd have to emulate the "nodeConnection" return structure in our custom cypher statements. I noticed that there's a other feature request around exposing the Where conditions to custom cypher here which would tackle it from the other direction if practical.

I see two nicer ways around this:

1. • Include edge properties in the available Where conditions, probably under some property that guarantees to avoid node property collisions
2. • Allow exposing certain properties of Edges and Nodes via a new directive directly as parameters, like we have with the @cypher directive, again somehow avoiding collisions with where and options

The latter is my ideal since the former would still lead to an inconsistent API around filtering when mixing with cypher queries. The former is probably more in line with you design though. For comparison here's the ideal vs the current solution:
query { nodes { otherNodes(verified: true) { property } } }
vs
query { nodes { otherNodesConnection(where: { edge: { verified: true } }) { edges { node { property } } } } }

This is also kinda related to my previous request that you responded to here but I thought it was work spinning this off as its own feature request.

TL;DR: The complexity of the "nodeConnection" query and result structures are a large price to pay just to included an edge property in the Where condition or Sort

[darrellwarde]

• Include edge properties in the available Where conditions, probably under some property that guarantees to avoid node property collisions

We're definitely not going to do this - if we wanted to, we would have moved all of the current arguments down into a node object and then also added a edge object. However, this would have completely broken every single existing 1.x.x query, so we took the stance of backwards compatibility here.

• • Allow exposing certain properties of Edges and Nodes via a new directive directly as parameters, like we have with the @cypher directive, again somehow avoiding collisions with where and options

Could you possibly explain this a bit more? Perhaps give an example of what this might look like in type definitions and then querying it?

[jbhurruth]

Yeh I imagined that would be the response to the first suggestion. I'm aware there's no good solution here so I'll probably just have to deal with it somehow.

The seconds suggestion would mean having a schema like:

type Thing {
    otherThing: Thing @relationship(type: "thingOf ", properties: "thingOf ", direction: IN)
}

interface thingOf {
    verified: Boolean @exposeParameter # OR @exposeCondition for "where"
}

and then being able to query like this:

query {
    things (verified: true) { # OR (where: {verified: true}) for @exposeCondition
        example
    }
}

The onus would be on the user to avoid collisions with the built in parameters like where, options, etc...
It would obviously lack the expressiveness of a standard where condition but could be useful. In fact, this approach could be used for my first suggestion to add the properties into the where condition without having to break into node and edge (comments).

[darrellwarde]

If I've understood this issue correctly after all of this time, this should now be supported via root-level connection fields!

So the above can be queried like:

{
  thingsConnection(
    where: { otherThingConnection: { edge: { verified: true } } }
  ) {
    edges {
      node {
        __typename
      }
    }
  }
}

Closing as I believe this is indeed the case.