-
-
Notifications
You must be signed in to change notification settings - Fork 4.8k
#4678: Converting strings to Date when schema.type is Date within agg… #4743
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
Conversation
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.
The code look good, can you add tests to ensure we cover all those 3 code paths and don’t introduce any regression in the future?
Codecov Report
@@ Coverage Diff @@
## master #4743 +/- ##
==========================================
+ Coverage 92.77% 92.81% +0.04%
==========================================
Files 119 119
Lines 8760 8813 +53
==========================================
+ Hits 8127 8180 +53
Misses 633 633
Continue to review full report at Codecov.
|
I need to keep working on this, I had forgotten about the other operators such as |
@cjbland no worry! Thanks for your contributions! |
…ry values to Date objects
stage.$match = transformMatch; | ||
} | ||
} | ||
this._parseAggregateArgs(schema, stage.$match); |
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.
Returned value seem unused.
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.
Thanks for picking up on that...I was trying to hurry and pushed the repo by accident (muscle memory from my day job, haha). I just pushed the fix.
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.
Thanks for the PR. I did a first pass at the review, so if we can get the style + a bit of comments on the hard parts that would be very appreciated ;)
_parseAggregateArgs(schema: any, pipeline: any): any { | ||
var rtnval = {}; | ||
if (Array.isArray(pipeline)) { | ||
rtnval = []; |
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.
can we transform in
return pipeline.map((value) => this._parseAggregateArgs(schema, value));
@@ -608,6 +597,55 @@ export class MongoStorageAdapter implements StorageAdapter { | |||
.catch(err => this.handleError(err)); | |||
} | |||
|
|||
_parseAggregateArgs(schema: any, pipeline: any): any { | |||
var rtnval = {}; |
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.
use const, and actually remove :)
} | ||
} | ||
else if (typeof pipeline === 'object') { | ||
for (const field in pipeline) { |
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.
declare const returnValue = {}
here and update all fields please
for (const field in pipeline) { | ||
if (schema.fields[field] && schema.fields[field].type === 'Pointer') { | ||
rtnval[`_p_${field}`] = `${schema.fields[field].targetClass}$${pipeline[field]}`; | ||
} |
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.
throughout the codebase we always write
if {
} else if ... {
} else if ... {
}
Can we keep the style please?
} | ||
|
||
var rtnval = {} | ||
for (const field in value) { |
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.
can we document what we expect the value to look like, I have trouble understanding what it does, and why we need the iterator, and recursion.
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.
Sorry for the newbie question...how do we take care of these? I've updated my branch to include your suggestions. Thanks.
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.
This function may work wrong way when "value" is
{ $exists: false }
@cjbland also it seems that many tests are failing :) You can run them locally with |
Thanks for the tip. I didn't realize the tests were failing but I see them now. I'll also fix the styling and take care of the other comments you've made. Thanks for taking your time to review this and sorry I'm not making it a little easier for you. |
@cjbland Thanks for getting this PR in. I started something like this a while ago and maybe we can collaborate on this. You can reuse whats in the MongoTransform.js for most of the transform keys. Here is my branch. |
@flovilmart I noticed 3-4 open issues and a lot of users requested transforming keys like pointers, default fields, and dates. I was trying to handle all use cases but I kinda lack complex aggregate queries to ensure it works. The current transform code is getting to be too much to handle considering there are ~40 mongo aggregate stages and could use some refactoring. The stages could be broken down as follows.
There maybe more that I don't know of. I can submit a PR and worry about complex queries as they come along. Here's an example of the most complex aggregate I've used. #1908 (comment) |
I'm definitely open to collaborating. The recursive aggregate function I wrote seems to work, my issue is the test case... I don't have any experience writing these tests, but I feel like the previous tests' |
@cjbland For sure, checkout the Contributing.MD for running test cases. There is a function Thats where your |
I added some comments to hopefully document my approach here. Personally, I'm not a fan of recursion, but this seems like the perfect candidate for it. The goal was to treat the query like a tree and traverse the tree to get to the leaf nodes. Once at the leaf node determine whether or not the value needed to be converted (based on the schema). I understand the structure isn't exactly a tree, but that's the best way for me to describe my intent. This should also handle any of the aggregation cases (since we aren't looking specifically for pipeline or comparison operators). |
@cjbland I like your approach better. Can you copy the tests from my branch to see if they run? |
Absolutely. Give me a few days, I have a lot going on this week. |
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've addressed these changes in the most recent commits.
I made the change that @dplewis suggested and added more tests for better code coverage. Hopefully this gets us a little closer. |
Is there documentation on which of these aggregate functions are supported by PostgreSQL? That seems to be why the latest tests failed for test 6417.3 - it didn't know how to handle the |
@cjbland that’s the reason why that test was excluded. Postgres only supports basic aggregates aka 3 stages no operators |
I'm happier with this now. Let me know what the next steps are. Thanks guys! |
@flovilmart I did some linter clean up can you do a final review? |
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.
Let's go!
@cjbland Thanks for the PR |
No problem, thanks for your patience. I’d like to contribute more if needed. |
@cjbland, thanks! Contributions can take many forms, and we always encourage people who want to start contributing a bit more to respond on some issues. If you feel you can address a few of the open ones, i’ll Gladly walk you through it and give the appropriate accesses so you can close / label them! |
@dplewis @flovilmart Any ideas on what's going on? |
I wasn't released part of 2.8.3 as this version is a hotfix for compatibility with the JS SDK. |
@flovilmart Got it. Saw it in the release commits so assumed it was part of 2.8.3 . |
We’re working on the 3.0 at the moment, and it’s likely gonna be the next release. Perhaps there will be a 2.8.4 before we cut the 3.0 |
Got it thanks. |
It’s always unlikely a release is ahead of master :) |
#4743) * #4678: Converting strings to Date when schema.type is Date within aggregate function * Added test cases to test new date match aggregate query * Added function to parse match aggregate arguments and convert necessary values to Date objects * Added missing return value * Improved code quality based on suggestions and figured out why tests were failing * Added tests from @dplewis * Supporting project aggregation as well as exists operator * Excluding exists match for postgres * Handling the $group operator similar to $match and $project * Added more tests for better code coverage * Excluding certain tests from being run on postgres * Excluding one more test from postgres * clean up
#4743) * #4678: Converting strings to Date when schema.type is Date within aggregate function * Added test cases to test new date match aggregate query * Added function to parse match aggregate arguments and convert necessary values to Date objects * Added missing return value * Improved code quality based on suggestions and figured out why tests were failing * Added tests from @dplewis * Supporting project aggregation as well as exists operator * Excluding exists match for postgres * Handling the $group operator similar to $match and $project * Added more tests for better code coverage * Excluding certain tests from being run on postgres * Excluding one more test from postgres * clean up
…Date within agg… (parse-community#4743) * parse-community#4678: Converting strings to Date when schema.type is Date within aggregate function * Added test cases to test new date match aggregate query * Added function to parse match aggregate arguments and convert necessary values to Date objects * Added missing return value * Improved code quality based on suggestions and figured out why tests were failing * Added tests from @dplewis * Supporting project aggregation as well as exists operator * Excluding exists match for postgres * Handling the $group operator similar to $match and $project * Added more tests for better code coverage * Excluding certain tests from being run on postgres * Excluding one more test from postgres * clean up
🎉 This change has been released in version 5.0.0-beta.1 |
🎉 This change has been released in version 5.0.0 |
I added a check to see if the schema field is a
Date
. If so, convert the string into aDate
object which themongodb
driver will accept for the aggregate function (it will not accept strings). I also added checks for thecreatedAt
andupdatedAt
attributes and converted them to the actual column names.