Repository navigation
Support native mongodb syntax for aggregation pipelines #7338
Description
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).
Activity
mtrezza commentedon Apr 12, 2021
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 commentedon Jul 16, 2021
I just noticed that the example in the issue actually contains 2 changes that are unrelated to each other.
objectIdto_idIssue (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
_idinstead ofobjectId. Not only for the JS SDK, but for all SDKs.RaschidJFR commentedon Jul 21, 2021
You're right. I decided to make that
_idchange 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 commentedon Jul 21, 2021
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 commentedon Jul 23, 2021
@RaschidJFR If you need any guidance on how to proceed please feel free to let me know.
[-]Support aggregation stage names starting with '$'[/-][+]Support native mongodb syntax for aggregation pipelines[/+]mtrezza commentedon Aug 12, 2021
Closed via #7339