Basic Aggregation - $match and $project

Hello,

So it’s really a question and statement fact, on how confusing it is to have commands such as $size which have subtlety different syntax based on the where they are used, either the MQL or the aggregation pipeline.

Requiring the user to have a good idea of where they are in the documentation (Which is very good) and the fact that these oddities exist to trip up the unwary at the beginning.

I always wondered how they crept in and couldn’t one syntax be used for all? Has this all come about because the aggregation pipleline development was separate at the start?

Hi @NMullins,

Great points and great questions! thank you for sharing!

First, slightly unrelated to your post, we are working on a new aggregation course that will address this in detail.

Your assumption is correct, we are also working on unifying the syntax a bit more within MQL.

As of right now the find() projection is the same as $project. You can use identical syntax for both.

An easy way to think about $match is that it uses regular find() syntax, however, if you want to write aggregation expressions and use that syntax within $match, then add $expr at the start of your match stage.

Hope this helps a bit. Let me know if you have any questions.

Thanks for the heads up on the re working on M121.

Great news on the unifying of syntax, it really does need it. There are to far too many edge cases to catch out the unwary e.g. $sum changing it’s behaviour depending on the $stage :slight_smile:

How will the changes be implemented, since I can’t imagine you want them to breaking changes?

  1. All flavors of a syntax supported?
  2. A switch on the database to enforce/warn of syntax changes?

I have found it surprising that the level of discordance in syntax was reached especially on something so relatively new. Were the engineers on some kind of race to the get through the next feature door, instead of resolving some of the basics :slight_smile:

1 Like