All possible paths with directions and huge estimated rows!

Neo4j Graph Platform
21

Nah,

You just need to remove the direction on the query

MATCH (n:location {lo_id: 69})
MATCH (m:location {lo_id: 489})
CALL apoc.path.expandConfig(n, {
    relationshipFilter: "cable",
    terminatorNodes: [m],
    uniqueness: "NODE_PATH"
})
YIELD path
RETURN path;

And read the docs too.

22

i already tested it and crashed my server :grin:

also tried to make a draw-back relationship of every cable that i make . but i was got worse so i step back .
this is the story:
we have multiple stations with two type of usage ( stations may be location or just a medium that connect a cable to another one because distance is too far )
then we add this stations and those mediums ( called joint ) into neo4j as node(s) and connect this nodes with relationships ( named :cable ) now operators need to resolve path between multiple stations and see some parameters based on this paths . i wrote this processor of path and will display map in visual way but i couldn't gather correct path from neo4j . its generated some path that does not include joints ( as mentioned before ) .
i have a question . how allShortestPath resolving path so fast in bidirectional way but we can't ? if i use relationshipFilter: "cable" server got crashed !

23

Thanks @bennu_neo :blush:

@mohsenshahbaziI don't advise deleting the directions because the query will be MUCH LONGER. If you could explain your use case, we might find another solution based on a new data model to speed up the query.

24

Nah,

You just need to remove the direction on the query

MATCH (n:location {lo_id: 69})
MATCH (m:location {lo_id: 489})
CALL apoc.path.expandConfig(n, {
    relationshipFilter: "cable",
    terminatorNodes: [m],
    uniqueness: "NODE_PATH"
})
YIELD path
RETURN path;

And read the docs too.

25

Nah,

You just need to remove the direction on the query

MATCH (n:location {lo_id: 69})
MATCH (m:location {lo_id: 489})
CALL apoc.path.expandConfig(n, {
    relationshipFilter: "cable",
    terminatorNodes: [m],
    uniqueness: "NODE_PATH"
})
YIELD path
RETURN path;

And read the docs too.

26

Nah,

You just need to remove the direction on the query

MATCH (n:location {lo_id: 69})
MATCH (m:location {lo_id: 489})
CALL apoc.path.expandConfig(n, {
    relationshipFilter: "cable",
    terminatorNodes: [m],
    uniqueness: "NODE_PATH"
})
YIELD path
RETURN path;

And read the docs too.

27

Nah,

You just need to remove the direction on the query

MATCH (n:location {lo_id: 69})
MATCH (m:location {lo_id: 489})
CALL apoc.path.expandConfig(n, {
    relationshipFilter: "cable",
    terminatorNodes: [m],
    uniqueness: "NODE_PATH"
})
YIELD path
RETURN path;

And read the docs too.

28

i already tested it and crashed my server :grin:

also tried to make a draw-back relationship of every cable that i make . but i was got worse so i step back .
this is the story:
we have multiple stations with two type of usage ( stations may be location or just a medium that connect a cable to another one because distance is too far )
then we add this stations and those mediums ( called joint ) into neo4j as node(s) and connect this nodes with relationships ( named :cable ) now operators need to resolve path between multiple stations and see some parameters based on this paths . i wrote this processor of path and will display map in visual way but i couldn't gather correct path from neo4j . its generated some path that does not include joints ( as mentioned before ) .
i have a question . how allShortestPath resolving path so fast in bidirectional way but we can't ? if i use relationshipFilter: "cable" server got crashed !

29

Thanks @bennu_neo :blush:

@mohsenshahbaziI don't advise deleting the directions because the query will be MUCH LONGER. If you could explain your use case, we might find another solution based on a new data model to speed up the query.

30

Download

Here it is

31

It's important to understand the context, otherwise it's just a loopy lattice problem that has been a known problem on big data analysis. Your path exploration can easily explode.

32

Well, it's not about the bidirectionality itself, it's more about traversing condition that may allow you to avoid traversing your entire graph or getting into cycles. But this is just possible knowing the model. If you can detail yours a bit more, we may get a chance to optimize your use case.

33

is there any way to simulate allShortestPath with bidirectional path search that so fast ?

34

what kind of additional data you need to know ?

it may kind of twist .