Support native mongodb syntax for aggregation pipelines

[RaschidJFR]

New Feature / Enhancement Checklist

• I am not disclosing a vulnerability.
• I am not just asking a question.
• I have searched through existing issues.

Current Limitation

In the JS SDK Parse.Query.aggregate() works really well in runtime, but the fact that stage names differ from the built-in MongoDB’s by the $ symbol and using objectId instead of _id represents an issue for compatibility, for example, when importing/exporting/debugging a pipeline in other tools like MongoCompass.

Feature / Enhancement Description

Parse.Query.aggregate() should support pipeline stage names in the same format as in mongodb so pipelines can be copy-pasted from/to other tools (mongo shell, mongo compass, etc), without having to edit each stage's name.

Example Use Case

Either of these parameters should be valid:

// current Parse SDK format
Parse.Query.aggregate({ match: { objectId: '1234' } });

// mongodb's standard format
Parse.Query.aggregate({ $match: { _id: '1234' } });

Alternatives / Workarounds

A current workaround is to develop/test/debug pipelines in MongoDB Compass (or your preferred tool) and then copy the whole pipeline into your js code and edit all stage names (only top-level, btw) by adding a preceding $ and substituting _id for objectId on top-level stages (2nd-level stages and deeper are already using _id).

3rd Party References

[mtrezza]

Thanks for suggesting!

I think this change would be welcome by the community. I have stumbled upon this inconvenience too, and it really can be quite a big one in a large pipeline.

The conversion back and forth between MongoDB and Parse pipeline syntax during development is additionally difficult because the IDE doesn't check the syntax, for the IDE it's just a large JSON.

So this proposed change definitely makes pipeline development easier.

[mtrezza]

I just noticed that the example in the issue actually contains 2 changes that are unrelated to each other.

• a) Remove $ sign
• b) Rename objectId to _id

Issue (b) is not reflected in the title or description. These should be distinctly discussed within this issue, or even be two separate issues with 2 separate PRs if their respective implications differ substantially.

Could you make this distinction?

Then we need to explore if there are any possible side effects when using _id instead of objectId. Not only for the JS SDK, but for all SDKs.

[RaschidJFR]

You're right. I decided to make that _id change last minute when I noticed that the method transformStage() is doing it anyway for $group. But indeed, I must make sure it works for other stages, for example, $match.

I think that changing only the $ part is just halfway through the solution as it would still be incompatible with a native mongo pipeline.

Would you agree @mtrezza that I should dig into this to release a complete solution in the PR?

[mtrezza]

Doing this in 1 PR combines 2 breaking changes into 1, so they will also deprecate together, which may be easier for the developer to follow and the developer only has to touch the pipeline once.

In any case, these 2 distinct changes have to be clearly reflected in this issue's and the PR's title and description, which they are currently not. Each of the changes requires separate tests and each of them needs to be evaluated separately regarding SDK compatibility.

[mtrezza]

@RaschidJFR If you need any guidance on how to proceed please feel free to let me know.

[mtrezza]

Closed via #7339