I have a directed Multigraph which is basically a number of directed graphs (of the same type), overlapped. There are quite a few queries in my use case that slice and dice this multigraph looking for shortest paths.
In general, this works. But... the return type of
allShortestPaths does not remain a
Path. It is basically a
List<Relationship> and this is the only way to access it as.
I think that I may have come across a use case where this is a bit limiting and it would probably be worth adding some functionality for
Graph to be able to propagate within CYPHER queries.
The majority of my queries return sensible paths. However, it is possible that with absurd parameters, the paths that
allShortestPaths returns have more than one components. In this case, I have no way (or so I think at least, from what I have tried so far) of knowing if the path is continuous or not.
In other words,
allShortestPaths should be applied at the induced subgraph that results from a query on the stored graph. This query (that produces the induced subgraph) is the one that determines if the solutions to
allShortestPaths will be valid or not. Right now, the filtering query is applied ON the
Knowing if there is a path between source and sink is very important to decide if the query results are meaningful.
This is because, if you assume that what
allShortestPaths returns is indeed a
Path, then you can safely iterate its relationships (and to an extent, it doesn't matter how you do that).
allShortestPaths returns "Paths" that are disjoint, then
List<Relationship> contains more than one
Paths that it is impossible to separate.
Path is a specialisation of
Graph, maybe it would be worth having named patterns return stuff as
Graph with the ability to apply CYPHER READ clauses further down the query. This could extend CYPHER logic operators towards things like
MATCH p=[...] WHERE p IS connected WITH filter(e IN relationships(p) where [conditions]) as f_e ...., or
MATCH G=(a)-[r]-(b) WHERE [conditions of subgraph] RETURN path_length(p) as L, clustering_coefficient(p) as C and so on.
The point is to make
Graph computable within CYPHER so that it is possible to pass them down the query chain from big towards smaller graphs.
This might make sense from the point of view of performance as well. At the end of the day,
allShortestPaths would run faster in the induced Graph because the induced graph would have vastly less edges than the stored graph.
Some of this stuff is probably done (still in a limiting way) via APOC if you filter the nodes and relationships you want, but contrast this with something like
MATCH U=()--() where
U is now a
()--() defines the condition of creating an induced subgraph (which could have any sort of shape and form). And then, once you have your
U, you could do something like
return path_length(U) as L, clustering_coefficient(U) as C...Or even
return U is connected as is_connected...or even
CASE WHEN U IS CONNECTED.... and so on.
Is there a way to decide if the Path is continuous at the level of CYPHER currently? I may of course have been approaching this consistently from the wrong angle and therefore cannot see the "easy" solution