MongoDB 3.6 brings powerful addition
to the aggregation framework, called expressive $Lookup.
$Lookup has this new additional form that allows for inner joins.
While additionally allowing us to be more expressive thus simplifying our pipelines.
Expressive $Lookup has the following form.
Their arguments are "from",
"let", "pipeline" and "as".
"Let" is the only optional field.
"From" is the collection we want to look at from.
It is identical to the simple $Lookup form.
"Let" allows us to bind variables to use in the next argument.
Again, "let" is optional.
If admitted the "pipeline" is considered uncorrelated meaning
the results will not be determined based on any information from the working document.
"Pipeline" allows us to specify logic as well as shape the return document.
It executes on the collection we specify, to "from".
We'll cover this more in a moment.
"As" is where we specify the name of
the field we want the results of the $lookup assigned.
It is identical to the simple $lookup form.
We'll refer to documents from the source collection that were aggregating over,
as the working documents.
"From" is still a required parameter for this form and works exactly as it did.
Specifying the collection we want to look up documents from.
Here, we will again specify air_airlines as the "from" field.
"Let" allows us to mine variables from the working documents,
to variable names we can define for use in the next argument.
Here, we'll assign the value of our airlines array to a variable called constituents.
Note the use of the field path expression when assigning this value.
If this is unfamiliar,
variables can be assigned exactly as they
are in dollar let expression when declaring Bars.
Remember though it's not the same format as in the dollar
let expression rather just name expression pairs.
A link to the dollar
let expression documentation as well as expression operators is below.
"Pipeline" is where the power of the new expressive lookup comes to full force.
Using the new $expr expression we can
use aggregation operators where we would normally use query operators.
To access the defined variables and "let" we pre-pend two
"dollar signs" just as we would to access user defined variables.
One dollar sign is still
a normal field path expression and will refer to that value within the document.
Here, name in the "pipeline" refers to
the name field in the current document in the looked up collection.
Again, this pipeline is executed on the air Alliance's collection.
Since we specified it as the argument to "from".
This pipeline is a fully featured pipeline with
all the power and expressiveness the aggregation framework provides.
Here, $$Constituents is referring to the constituents variable we created in "let".
We bound the value of the airlines array to the named constituents.
So, we will filter out documents where the name the airline isn't in Constituents.
And just like the simple form of lookup,
"as" is the field name we want to have the results of the lookup assigned to.
Just as the previous lookup it will be an array of
matches or an empty array if there were no matches.
Also just as the simple form,
it will return the entirety of the matching document by default.
Let's look at this in action.
As the argument to "from" we specify air_airlines.
And "let", we bound the airlines array to the name constituents,
which we'll refer to in the pipeline,
where we filter out documents where the name isn't in constituents.
Let's run it to see the results.
Now let's look at the previous example where we only
wanted the ID of the airline, name and alias.
We use an addFields stage to transform the airline's array.
Extracting the name, alias and information
from airline assigning that one to a key called ID.
And just the name Alias and ID within the airline's array.
Using the new expressive lookup form,
we still specified air_airlines to From.
We bound the information from the airlines array to a field called
Constituents that we can use within our Pipeline.
And in our Pipeline we've just added a project stage.
Where we remove the inner score ID information,
project the name Alias and reassign the airline field to the key ID.
And we got the content we wanted and the shaping was done before joining,
so we ultimately used less space to accomplish the same task.
You're probably beginning to understand
the powerful possibilities available with the new expressive form of lookup.
Let's summarize what we've covered so far.
The Pipeline in expressive look up is
a fully qualified aggregation pipeline and subject to the same restrictions.
Operates over the collection specified to the "from" field.
Accesses variables bound inlet by prepending two dollar signs.
Will execute for every working document.
This $addField stage, that transforms the airlines field,
iterating over the airline's collection,
extracting the name, alias, and airline info.
Reassigning the airline to a new key called ID.
Let's see the result.
Great. It worked as expected.
We can see we transformed the documents within the airlines array,
after the lookup stage returned them.
Exactly what we wanted,
but let's look at a better way.
This is where the new expressive $lookup form comes in.
