Undirected Cypher queries renders incorrect relationship directions in graph view

[prrao87]

I think we could do a bit better with drawing the directions on relationships when the user specifies undirected Cypher queries. Consider that I have a schema as visualized below:

Note that there are no Client-Client relationships in this graph (the only paths between two clients are through a merchant).

In order to run a multi-hop query to answer questions about clients and merchants via this schema, I cannot specify the direction of the relationship, as to reach other clients, I have to pass through a merchant in an undirected manner, because we cannot have a directed relationship from merchant to the client.

To return paths in this case, I resort to an undirected query as follows:

MATCH (c:Client {client_id: 679})-[t:TransactedWith*1..3]-(m:Merchant)
RETURN * LIMIT 10;

When the paths are returned, the directions of the arrows are incorrect (we get some edges pointing from a merchant to a client) -- it seems like the arrows are drawn based on the order in which the nodes appear in the path.

Suggested behaviours

Option 1

Disable arrow rendering (show undirected edges) if the user specified an undirected query without any directions.

Option 2

The schema is of course the "source of truth" for the directionality of a relationship. If option 1 is difficult or not a good idea for any reason, can we instead just force G6 to render the arrow directions based on the schemas, regardless of the path objects being returned? For e.g., if we got [client_1]--[merchant_1]--[client_2]--[merchant_2], we know from the schema that we can only have arrows in the [client]-->[merchant] direction and not the other way around.

[mewim]

The Explorer app does not infer edges from the order of the path but simply draws each rel based on the src and dst returned by the core:

explorer/src/components/ShellView/ResultGraph.vue

Lines 526 to 527 in 075a217

	source: this.encodeNodeId(rawRel._src),
	target: this.encodeNodeId(rawRel._dst),

So it seems that in this case the core does return a rel with merchant as src and client as dst. If this is not desirable, maybe the core should return the rels in reverse order rather than implementing a hack based on the schema/path order at the Explorer side.

[prrao87]

Ah, I think I know what's happening. When sending an undirected edge Cypher query for transitive paths (where a particular node appears in multiple distinct paths), we will return redundant paths (in both directions). So the arrow drawing rules as you showed simply render the source and destination based on what it receives - it seems like the latest value in the list of paths is what's drawn.

Sometimes, I see the arrows drawn in both directions when I run this query:

MATCH (c:Client)-[t:TransactedWith]-(m:Merchant)-[t2:TransactedWith]-(c2:Client)
RETURN * limit 50;

Client 1 and merchant 50 have arrows between them in both directions as multiple paths pass through merchant 50, but the order in which they were sent to the front end is not guaranteed. So, sometimes, the wrong direction path is drawn instead.

I'm not sure that anything in the core needs to be changed for this, but I'm also not sure what's a good solution. Clearly others like Neptune and Neo4j have figured this out, so I'm sure G6 has a way too.