Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(NODE-2883): Aggregate Operation should not require parent parameter #2918
fix(NODE-2883): Aggregate Operation should not require parent parameter #2918
Changes from 3 commits
dda834d
5b4bc3f
895e447
f3d21de
d54fff4
e59f480
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a nit, optional
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed that because when ns.collection is set to the empty string, we set the target to the empty string instead of
DB_AGGREGATE_COLLECTION
, which leads to a few test failuresThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah Fascinating, I feel like that makes this worthy of more explicit code.
This but with curly braces
Or we can bring back the ternary, Or leave it as is with a comment,
// covers undefined and empty string
, It's just easy to over look if the code itself or a comment doesn't call it out, what do you think?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah that sounds good. Makes sense to have it be more explicit so the next person to see it and thinks to change it won't have to go bughunting like I did
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lol I just noticed this after doing my review... I think a comment would be better; explicit undefined checks are somewhat weird and puts into question why we aren't validating for the other excluded cases... if we're concerned about nullish values but only these ones, why aren't we throwing errors on the other kinds? Edit: just to clarify, what I'm trying to convey is that reading that code with just that check there communicates to me that we are ok with assigning
null
to the target, but notundefined
, and that, logically, feels wrong; but if we aren't ok with assigning null to the target, then I would expect some sort of validation that throws an error if we somehow do pass in null, and that validation is missing here, which makes the intent of the code seemingly inconsistent (it's important to remember that typescript types don't guarantee that at runtime only those types will actually be passed in those inputs, so "manual" validation is still valuable wherever such validation is important).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok one more code suggestion ^
But also reverting to the ternary and using the same nullish that was there before along with a comment is a good solution to me as well. Your point is correct we should make sure that we are actually filtering for our intention and not leaving a gap that might suggest null is okay here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend against the potential behavior change unless truly necessary; and if we do make that behavior change, we'd want to throw on ns.collection not being null/undefined so that we can guard against unexpected input sneaking through (one of those runtime errors)... feels like overkill for this ticket though, hence easier to just keep the original behavior (
this.target = ns.collection || DB_AGGREGATE_COLLECTION;
)