-
Notifications
You must be signed in to change notification settings - Fork 10
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
feat: add support for query that have aggregation but missing group by #124
Conversation
This comment has been minimized.
This comment has been minimized.
Codecov Report
@@ Coverage Diff @@
## main #124 +/- ##
============================================
+ Coverage 77.86% 78.13% +0.26%
- Complexity 512 524 +12
============================================
Files 87 89 +2
Lines 2679 2707 +28
Branches 266 268 +2
============================================
+ Hits 2086 2115 +29
+ Misses 431 430 -1
Partials 162 162
Flags with carried forward coverage won't be shown. Click here to find out more.
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
* this transformer removes all the non-aggregated expressions. So, the above query will be transformed | ||
* to: | ||
* | ||
* SELECT COUNT(DISTINCT document->>'quantity' ) AS QTY |
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.
Not sure if we should go this route. We have never transformed the user-given query to a different non-equivalent query just because some database does not support it. In fact, this transformation alters the input selections and removes some of them. This might result in unexpected/undesired effects in the clients because they are asking for 2 selections, but, we only return 1 silently ignoring the other.
The query transformer in Mongo only builds equivalent queries by modifying the given expressions to other equivalent forms or adds some expressions to support the modification. But, the overall query is transformed to another equivalent query supported by the database. We neither remove anything nor transform to a non-equivalent query. Ideally, for such scenarios, we should fail (even in Mongo if that's not the case today). I suspect, the DB itself is not returning the rows in case of Mongo.
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.
For example, in Mongo we convert "DISTINCT_COUNT" into "$addToSet" in the "$group" stage and add "$size" in the "$project" stage. But, the query is still equivalent.
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.
Mongo internally does that and discards them. And, thought of the above path, but have to do this for backward compatibility as currently in the Query API layer, we are not discarding those queries.
e.g Mongo Query for the above sample query
[{"$match": {"$and": [{"price": {"$lte": 10}}, {"item": {"$in": ["Mirror", "Comb", "Shampoo", "Bottle"]}}]}},
{"$group": {"qty_count": {"$addToSet": "$quantity"}, "_id": null}},
{"$project": {"item": 1, "qty_count": {"$size": "$qty_count"}, "price": 1}}]
Response to the above query from mongo (selections are discarded):
[{"qty_count":3}]
This comment has been minimized.
This comment has been minimized.
@suresh-prakash As discussed,
I am still testing this one with a custom build, if any issue, will fix it first. |
Description
As part of the issue - #123, This PR
Solution:
Mongo:
Postgres:
Testing
Checklist: