Graphlookup query results don't make sense

Hello. Im unable to understand the results talked about in the post below. The graphlookup query matches the destination airport of Route X with source airports for all other available routes. However, if you look at the results of this query for the document with objectid 56e9b39c732b6122f878b0cc, the very first result going from ORY to IBZ does not match with its predecessor route going from AKL to BNE.

To be doubly sure of my interpretation, I created a sample db with the below data.

| id | Dst| Src|
| 1 | A | C |
| 2 | C | F |
| 3 | F | M |
| 4 | F | B |
| 5 | M | G |
| 6 | G | Y |
| 7 | Y | B |
| 8 | H | I |
| 9 | I | J |
| 10 | J | K |

And ran the below query:

db.Test2.aggregate( [{
   $graphLookup: {
      from: "Test2",
      startWith: "$Src",
      connectFromField: : "Src",
      connectToField: "Dst",
      as: "reportingHierarchy"
}] )

Results from this query for id 1 below:


Ideally, this query should give the below result for id1: id 2-3-5-6-7 and id 2-4. How do I make sense of these results, the query seems to be traversing my documents and reporting results in an order that doesn’t seem to make sense.

What you are missing is numberOfAdditionalStops: 3 for ORY-to-IBZ. That means the ORY-IBZ is not directly connected but is 2 more nodes down the graph. If you look at BNE-LST you see that numberOfAdditionalStops is 0, which is expected BNE is destination of AKL-BNE and source of BNE-LST. The route(s) to reach ORY-IBZ are not listed and the three little dots indicates that some of the routes are not listed to make the text smaller.

What makes your example confusing is that you inverted startWith, connectFromField and connectToField compared to the example in the article.

But let’s try to analyze, if your expectations are correct. Src(x) will indicate the Src field of document id:1

Src(1) is C and Dst(1) is A , since we start with $Src we then start with C
connectToField is Dst, so first lookup is for nodes where Dst(n) == C, so node id:2
connectFromFIeld of id:2 is Src(2) == F so we look for Dst(n)==F, so node id:3 and id:4

I will stop here because you did not list id:4 in your expected result, so your expectation does not match your data or your aggregation.

I think that inverting src and dst compared to the example created the confusion.

Hello Steeve!!! Thank you for your comments! :grin: :grin: :grin: :grin:

Okay, so the # of additional stops bit threw me off as well which is why I ran the query on a new db.

I list id 4 in my expected result… There are two branches Im expecting if we run the query on id 1. The first branch is 23567. The second is 24. Ive listed both the paths in my question above…

1 Like

I see that now. I misunderstood that part. Thanks for the clarification.