We had a look at a lot of operators and a lot of pipeline stages
and of course, I encourage you to dive into the official docs. Now I want to have a look at some stages
which we saw before but which you have to get
right
and therefore let's see how we work with these stages.
Let's say we want to find the 10 users, the 10 persons with the oldest birth date, so the lowest birth date
so to say and thereafter we want to find the next 10,
so like if we had pagination in place. Now for that, first of all, I will add a project phase to convert
my date,
I also could sort it whilst it's in string form but I still want to convert it also to practice this again.
I'm not interested in my ID,
I will keep my name and then I'll have my birth date field which I will convert to a date and the input
for to date is dob date of course, referring to this field here.
Now let's try that out,
if I run this command, I get persons where the name and the birth date is available,
now we can sort on this birth date.
So let's add a new stage here, sort and let's sort by birth date as I just said,
so we can simply say birth date, referring to our newly added field here in ascending order so that the
lowest birth date comes first.
If I do that, well then I have a bunch of birth dates here which look pretty low and keep in mind, we
only see 20 results here because we get back a cursor,
so we get pretty old persons or pretty old people there.
Thanks to my date ordering, the very oldest person is Mrs Victoria Hale because she's born on 7 September
and even though this person here, I'm sorry I don't know how to pronounce this, even though this person
is equally old in terms of years,
it's not the case in terms of days.
So this is the oldest person in the dataset,
now I only want to see the top ten
and for this, we can add another stage which we saw before with the find method but haven't seen here
yet, the limit stage.
Now limit is pretty straightforward,
we just define how many entries we want to see, 10 let's say. If I copy that and I print that out,
we now see 10 records only,
there is no type it to see more anymore because we exhausted our cursor here because we only see 10
and therefore, this is what we get back.
So now we have the top 10 oldest people in our dataset,
now let me quickly change that name to make it a bit more readable,
I will use concat here to build a name,
I will not do the whole change with the uppercase starting characters to keep this a bit smaller but I
will point at name first,
add a whitespace and then use name
last here simply because
now if I use this stage, we have single lines for the persons.
So now I got my top 10 here which is great of course,
now let's say we want to see the next 10.
We can do this with another stage and that is the skip stage which we have to add prior to limit,
so now we skip the first ten records and show the next 10.
If I now copy this and I paste it in, we see different names because we simply skipped to the next page you
could say.
Now what's really important here is the order of skip, limit and sort.
If I had skip after limit like this and I copy that, I get back no results because what happens here
is I do my projection, I sort
then I fetch 10 persons and then I skip by 10 persons,
so what's remaining,
well zero.
So that is why this order is important,
the order did not matter on the
find method, there you could chain the skip and limit methods onto your cursor as you want it. Here
it does matter because your pipeline is processed step by step.
The same of course is true for sorting,
if I do sort after this, so after skiping and limiting, I get a totally different set of results because
if I now execute this, I have people who are not that old, they're born in the 1980s, even 1990s. The reason
for that is that I simply skip the first ten persons in my dataset as it's stored in the collection
and then I take the next 10 and I only sort these 10 persons.
So this is really important to understand, the same of course would be the case if you have a match in
there. If we want to find the oldest males, let's say, we should include a match phase and we should include
that early to limit the amount of data we have to work with in the other stages.
So here, I can match for gender being equal to male of course
and if I do that, everything will be fine and I get the 10
oldest men here,
well not right now because the order is incorrect, we just broke that right
but we do match.
However if I fix the order like this and I execute it then, now we do have the 10 oldest men
and as I mentioned, the order does matter because if I do match after sorting, which I can do, I can filter
at any point of time, I don't have to do this at the beginning but if I do match here,
I get back no results at all
and the reason for that is that gender is not included in my projection phase,
so I try to match something which is not there.
If I do add gender here in my projection phase, then I will get results
but now I still have a sub-optimal setup because I do match only after transforming all the elements
in my collection.
So I will have projected all the females here too
even though later, I'm only interested in the males,
so I should reverse this. Now actually mongodb will do some optimizations for you,
you'll find details in the next lecture which has an article. Mongodb does some optimizations for you
to optimize your pipeline, so it might very well have fixed this issue here for us but you shouldn't
rely too much on that and you should try to build correct pipelines with the correct order that optimizes
for performance
and of course well, builds the kind of structure you want to have.