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

[ninesunqian]

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 !

[tard_gabriel]

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

[ninesunqian]

tard.gabriel:

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

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.

[ninesunqian]

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.

[ninesunqian]

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

[clem]

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!

[ninesunqian]

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+su...