How to connect multiple "match", previous match's result are current match's beginning?

Hello everyone!
I have a complex requirement, I need connect three match. I need help!
Details are as follow:
1 start from node "e", find its “refer” neighbors, named "reference" ( "b" and "d")
my code is
"MATCH (self)-[e:REFER]->(reference)
where id(self) = $selfId
"

2 for each reference, find their "include" path from seen nodes. ( [ "ab"], ["cd"])
my code is
"MATCH p = (reference)<-[r:INCLUDE*]-(seen)
WHERE id(seen) IN $seenList
RETURN p
LIMIT 1
"

3 for each node in each "include path", find their out neighbors [["ab1", "ab2"], [["cd1", "cd2"]
I have not write the code.

I don't know how to connect step 1,2,3.
Looking forward to your reply!
Thank you very much !

MATCH (self)-[e:REFER]->(reference)<-[r:INCLUDE*]-(seen)-[*]->(n) WHERE id(self) = $selfId AND id(seen) IN $seenList
RETURN n LIMIT 10

You can change the LIMIT value as you want

You need to define with ( labels, property name, relation type, etc. ) a little bit more your graph idea, because in a real environment with many nodes an relations this query will crash or take too long. And it's difficult for the community to help you if there is no context or soul to your project because we will try to understand the need first.

Note: As the database nodes ids can change or being recycle over time, it's usually not a good idea to use them for a MATCH close especially in a production environment.

You can create non recycled ids with the randomUUID function

Thank you for your reply!
Actually the graph is a big tree if there are only “include” edges. Refer edge can connect any node in the tree. A “include path”of a node is the path from the root to it.
I travel from a node in the tree to the leaf direction.when I meet a refer edge, I need get the target edge (reference),and the include path the reference , and the neighbors of the nodes of the include path. In order to improve the performance, while getting include path,stop if it meet seen nodes. Because I saved seen node in the client end.

It’s a goo idea.But I have two questions:
1 I don’t know whether it can work if the reference is the root (the root has no include path)
2 I need return the reference, the include path and the neighbors of the nodes on it. If multiple query can consist a pipeline, it maybe better than a long pattern query.

About using id(node): if the id of each valid node will not change, i think it is safe.

Still, I wouldn't do create a system that depended on Neo4J's built-in ids... If you do, you've created a potential software time bomb: it will be easy to forget the requirement that you can't/shouldn't delete Nodes and create new ones. A bug due to changing id's looks like it might be hard to diagnose as well since I imagine it will be hard to reproduce.

And if you do realize it, you'll potentially need to fix a lot of code. IMHO, It doesn't make sense to create this potential technical debt.

Worse, suppose you leave the organization that's using the code and somebody new to Neo4J decides to repurpose your code for another project?

Way too many preventable bugs could have been nipped in the bud by programmers who were more careful in their assumptions!

thank you all!I will not use id as the parameters .
For connect query,I get the answer in this link https://s3.amazonaws.com/artifacts.opencypher.org/website/ocig6/Nested%2C+updating%2C+and+chained+subqueries.pdf

Do you mean: Even if I don't touch the data, the nodes' id will still changes ?

They actually DON'T change if you aren't deleting nodes but in theory they COULD and you're supposed to use a unique constraint for every Label and use that property as your searchterm.

Also you're supposed to convert to elementId() (which includes which database and transaction ID). :slight_smile:

It's annoying.

I created a sample of your diagram:

Ran this query:
match (a:E) where a.name = "e1"
CALL apoc.path.spanningTree(a,{relationshipsFilter:'REFER|INCLUDE|INCLUDE_PATH', maxLevel:3}) YIELD path
RETURN path

Result:

1 Like

Yes, you've convinced me. I'm going to add a UUID property and use it as an index. But I'm not sure how much less efficient it will be to use a UUID as an index compared to using the id directly."

Actually, what I wanted was the path from d and b to the root, as well as the nodes adjacent to the path. But later I realized that the adjacent nodes on the path are not necessary. Nonetheless, thank you for your help.

I assume both are backed by O(1) hashtable lookups. :) But I'm not an expert at the internals :)

I'm finding it hard not to use internal ids at all
for example

"MATCH p=(n)<-[:INCLUDE*]-(root)
WHERE n.uuid in ["aaa", "bbb", ... ] AND root.uuid = "yyyyy"
RETURN nodes(p) AS nodes, relationships(p) AS edges "

I have to use the edge.startNodeElementId and edge. endNodeElementId (the internal id of the startNode and endNode of the edge.

so I have to save n's internal id in the recent past. Then here comes the question, How long can I save it locally, and when I must update it ?