support root collection column references #75
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
codedmart
reviewed
Jun 12, 2024
| // TODO: This selection illustrates that we end up looking up the relationship twice (once | ||
| // with the key `class_students`, and then with the key `class_students_0`). This is | ||
| // because the queries on the two relationships have different scope names. The query would | ||
| // work with just one lookup. Can we do that optimization? |
There was a problem hiding this comment.
Can we create a ticket for this TODO as well please.
There was a problem hiding this comment.
Sure thing, I filed https://hasurahq.atlassian.net/browse/MDB-164
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Supports root collection column references correctly. We were using
$$ROOTwhich just refers to the current collection. Root references actually reference the collection of the nearest query up the tree in the query request. The query plan that we produce from a query request is structured differently, and hasQueryvalues in positions where the request doesn't. So this PR introduces a "scope" concept in the query plan to capture the intended reference scopes from the request.A couple of notes here on how the MongoDB expressions are evaluated:
The special variable
$$ROOTrefers to the "current document" being processed by the pipeline. When we look up a relation we use a$lookupstage which has it's own pipeline. If we reference$$ROOTinside if the$lookuppipeline then it resolves to documents in the related collection - the one we are looking up.On the other hand the
$lookupstage also accepts aletmap to bind variables. When we reference$$ROOTin a variable assignment in thisletmap it references the collection we are joining from, not the collection we are joining to. And then the variable bound in theletmap is in scope in the$lookuppipeline.MDB-6