Doubts about the solution for the final lab on Chapter 3 (on $graphLookup)

[N_A_N_A14 (Sunil)]

I’m looking at the detailed answer of the lab on Chapter 3. In the below part of the code, I cannot understand what is the connectToField called name. I cannot find name in the airlines array in air_alliance collection. I tried replacing this name with name1 or namexxx and the result returns just the same - so I’m assuming this means name is like a pseudo name used on the fly to refer to all items in the airlines array.

{
  $graphLookup: {
    startWith: "$airlines",
    from: "air_airlines",
    connectFromField: "name",
    **connectToField: "name",**
    as: "airlines",
    maxDepth: 0,
    restrictSearchWithMatch: {
      country: { $in: ["Germany", "Spain", "Canada"] }
    }
  }
}

Also, the explanation of the next step states

We then iterate over all routes up to maximum of one layover by setting our maxDepth to 1.

I thought the stops field in air_routes was the one to be used to filter for no of layovers. How can that be achieved by using maxDepth =1 instead ?

[steevej (Steeve Juneau)]

If you look at the $graphLookup documentation you will see that connectFromField: and connectToField: are both fields from the from: collection.

In the case the from: collection is air_airlines and a field named name does exist.

[N_A_N_A14 (Sunil)]

Thanks for the response Steeve.

However, it maybe my original post wrongly stated connectToField - its connectFromField instead. I’ve replicated the behavior at my end again, and put a screen shot showing 4 different executions with various names in the connectFromField (all else being same) - it doesn’t seem to matter what it is called. So my confusion remains!

[steevej (Steeve Juneau)]

The field maxDepth is 0.

The first lookup (depth 0) is done using startWith which is matched to connectToField in from : air_airlines.

The next lookup operations (depth > 0) are done using connectFromField which is matched to connectToField in the same ***from : air_airlines.

But since maxDepth is 0, only the first (depth = 0) lookup is done so connectFromField is never used.

[N_A_N_A14 (Sunil)]

Thanks a lot Steeve. Now its clear.

Perhaps the original documentation should explain these matters more elaborately.

[steevej (Steeve Juneau)]

Writing documentation is an art, often harder that writing code.

Code is interpreted and run by computers, you got it right or wrong.

Documentation is interpreted by human, you never got it right for all.

Kudos to all technical writers.

[N_A_N_A14 (Sunil)]

Agreed!

Perhaps best to allow users to suggest edit - like Microsoft does using GitHub.

[Stennie]

@N_A_N_A14

Perhaps best to allow users to suggest edit - like Microsoft does using GitHub.

Hi @N_A_N_A14

There are actually several paths for contributing feedback or even directly to MongoDB documentation via GitHub PRs. I’ve outlined these paths below in increasing order of effort for both yourself and the documentation team.

---

1. Provide feedback directly via a documentation page

• The bottom right of most MongoDB documentation pages will have a “Give Feedback” button pinned near the bottom right of the visible page:

  

  The feedback widget is designed to capture quick directional feedback as well as more detailed suggestions.

• The first step of feedback is a star rating for helpfulness:

  

  Helpfulness is subjective, but the aggregate rating and velocity of ratings are indicators for pages that may need more urgent review and improvement.

• The second step prompts for a general category of feedback:

  

  Feedback categories may change depending on your star rating. For example, in the above screenshot I rated a page as Somewhat Helpful (3 stars) and the suggested categories are common areas for improvement.

• Finally, you can also provide a comment with more detailed feedback and suggestions:

  

  In earlier iterations of feedback widgets we prompted for freeform comments earlier and linked directly to “Edit on GitHub” to create a PR. However, this level of detail takes the most time to review and is difficult to prioritise at scale without directional signals like the first two steps.

---

2. Report an Issue in the MongoDB Jira DOCS project

You can Report an issue or make a change request by creating a DOCS issue in the MongoDB Jira Issue Tracker.

This path doesn’t capture as much context as the feedback widget embedded in the online documentation and may take longer for the team to review.

A great DOCS issue should include enough details to be actionable such as:

• url for the relevant documentation section
• browser version used (for display or UX issues)
• suggested improvements
• links to relevant community discussions

---

3. Contribute directly to the documentation

MongoDB server and driver documentation source is available on GitHub and you can contribute to the documentation by signing the contributor agreement and making a pull request on GitHub.

With this path I recommend first creating a DOCS issue so there is context for why you are making a change as well as an issue for the documentation team to track via their Jira dashboards and workflow.

Any significant changes may require some discussion to agree on approach, and there are expectations around writing, style, and process to help create a consistent high quality experience as per The MongoDB Documentation Project. The Practices and Processes section provides a good overview for contributors.

---

We appreciate any feedback and contributions provided, including suggestions on how to improve those processes!

Regards.
Stennie