We also have our count stage. The stage counts all incoming documents. The argument to count is the field name on which we're going to collect that count value in a document of the results. In this case, I'm going to filter our collection so we only look at documents that are terrestrial planets. Here, I'm specifying that match where the type of the document will have the value terrestrial planets. Then from the results from match which are then dispatched to the project stage, I'm going to filter only name and number of moons, removing ID as we've done before, and from all of the documents coming from the pipeline, I'm then going to count them. The count will give me back a result documents which has a field that I specified here, terrestrial planets, which contains the value of number of documents that are of type terrestrial planets. Now for this particular pipeline here, where the end result is going to be the count of the number of documents which have a type of terrestrial planets, the project stage here is a little bit of an annoyance. It doesn't really interfere with the end result of the pipeline. So if we just remove it and we just have a match and then count, we can see that I get exactly the same execution and exactly the same results having or not a project in between the match and the count. Lastly, let's look at the sort. Sort needs to be supplied with the field we want to sort out on. In this case, if I'm going to project name and number of moons, I can sort on the fields that I'm collecting from the incoming pipeline. So in this case, if I want to sort on the number of moons descending, I'll get the result as expected where I get the planet which has more moons first and, on that order, to the ones that have absolutely no moons like sun, Mercury and Venus, poor guys. An important aspect to refer here is that the sort stage is not limited to just one single field. You will operate on multiple different fields in combination as we would do in normal queries and find operations. If we want to sort first on one field and then on another, that is still possible in the aggregation pipeline stage as well. So, let's say here, for example, that I have this different project where I'm going to project as well apart from name and number of moons, the field has magnetic field which is a building field. In the sort stage, I can specify that I want to sort on as magnetic field the descending and number of moons descending. By executing this specific query, we get a very similar result as before where we're going to have Jupiter, Saturn, Uranus, and so on. The only difference is that, for example, sun and Mercury will come before Mars. So, how is that possible? Well, the results are being sorted first on the field as magnetic field equals true and then on the number of moons. So first, I'm going to have all the ones that has magnetic field is equal to true, and then after that, I'm going to sort on the number of moons for the result set. Now if sort is near the beginning of our pipeline and placed before a project and then wind and the group stage, it can take advantage of indexes. Otherwise, this sort stage will perform an in-memory sort which will greatly increase the memory consumption of our server. Sort operations within the aggregation pipeline are limited to 100 megabytes of RAM by default. To allow handling larger data sets, we need to allowDiskUse, which is a aggregation pipeline option that we can provide to the aggregate function. By doing so, we will be performing the excess of 100 megabytes of memory required to do do a sort using disk to help us sort out the results. So in short, sort, skip, limits and count are functionally equivalent to the similarly named cursor methods. Sort can take advantage of indexes if it's near the beginning of our pipeline and before a project, group, or end-one stages. By default, the sort stage will only take up to 100 megabytes of RAM. For more than that, we will need to provide the allowDiskUsage option equals true to our pipeline. If we do not do so, the operation will be terminated on the server. And that's all we have for you in cursor-like stages of our aggregation pipeline.
