-
Notifications
You must be signed in to change notification settings - Fork 54
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 ability to explain groupNode
and it's attribute(s).
#641
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #641 +/- ##
===========================================
+ Coverage 57.14% 57.32% +0.18%
===========================================
Files 122 122
Lines 14662 14753 +91
===========================================
+ Hits 8378 8457 +79
- Misses 5567 5573 +6
- Partials 717 723 +6
|
groupNode
attribute(s).
6f3aabe
to
d021080
Compare
"childSelects": []dataMap{ | ||
{ | ||
"collectionName": "author", | ||
"docKeys": nil, |
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.
question: not quite sure if this is implemented, because I haven't been able to hit the dockey
filter case inside the child group.
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 leave for now as we investigate
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.
Blocking issue/suggestion regarding the change to the GroupBy
struct (int vs Field)`.
Will give huge praise for very expansive testing though!
Query: `query @explain { | ||
author (groupBy: [name]) { | ||
name | ||
_avg(_group: {field: _avg}) | ||
_group(groupBy: [verified]) { | ||
verified | ||
_avg(_group: {field: age}) | ||
} | ||
} | ||
}`, |
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.
Now thats a complicated query 😅
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.
Couldn't remotely tell you whats its trying to do in plain english
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.
slowly piecing it together lol, fun test!
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.
Groups everything by name, and shows average of average of the age groupedBy verified.
"childSelects": []dataMap{ | ||
{ | ||
"collectionName": "author", | ||
"docKeys": nil, |
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 leave for now as we investigate
FieldIndexes []int | ||
Fields []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.
suggestion(blocking): I'm very hesitant to make a change like this without input from Andy, just for the sake of the explain system.
As I understand it, the goal here is to be able to efficiently get the corresponding FieldName when doing the GroupBy
explain, but this change affects a lot of other places (as you know, since you had to update them all).
But, as I understand it, the mapper already has a utility to convert index
into FieldName
without needing to make a change like this.
eg: n.documentMapping.TryToFindNameFromIndex(index)
. Which you are already using for the order fields. Is it not possible to use this utility as well for the groupby fields? Which would mean you don't have to make this change?
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.
Fair point John. I do think however that the codes reads a bit nicer with this change. For example, this:
for _, keyField := range keyFields {
reads better than this:
for _, keyField := range keyIndexes {
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.
Fair point John. I do think however that the codes reads a bit nicer with this change. For example, this:
There's certainly more than a few rough edges w.r.t the mapper system, which are being tracked/tackled in #606.
The explain PRs should make an effort to not change core planner functionality, if it does need a refactor for something, it should be done in a seperate PR.
For this specific PR, as far as I can tall, the TryToFindNameFromIndex
seems like it should be sufficient to circumvent this larger change.
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.
It doesn't really change the functionality though. It merely adds information to a variable (from []int
to []struct
) and changes its name. I think of it as if it were already a struct, it would just be adding a struct 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.
You make a fair point, however this is basically just adding an additional field (is nicer IMO). It's nice to have a guarantee of field index always having a corresponding name.
I wrote the TryToFindNameFromIndex
function for finding indexes of ordering elements in orderNode
. Using that function wouldn't guarantee that the field name exists (even though it should), and obviously is not as nice doing lookup if we don't have to.
One other thing I could do to reduce the changes (however would still prefer this approach better), is I could still pass in only the list of indexes into the functions whose signatures were changed to mapper.Field[]
from int[]
.
LMK what you think, at the end of the day this is a very safe change as it's just tagging an additional field, and the previous field stays there as it was before. I would be concerned if I had removed a field haha
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 still prefer to try to minimize changes beyond utility funcs for explain PRs.
Although technically this is a small change ([]int
to []struct
) as Fred pointed out, it does sprawl all over the implementation.
Its OK for now, but lets try to minimize this stuff in the future.
d021080
to
98a5d89
Compare
98a5d89
to
08a13d1
Compare
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.
LGTM!
groupNode
attribute(s).groupNode
and it's attribute(s).
…cenetwork#641) - Resolves sourcenetwork#525 - Description: Makes `groupNode` explainable. Explains the child selects list of attributes of `groupNode`. Explains the attribute that represents the field the `groupBy` is on. Includes integration tests for various types of `groupNode` explanations. - Request: ``` query @Explain { author ( groupBy: [age, verified], ) { age _group(filter: {age: {_gt: 63}}) { name } } } ``` - Response: ``` { "data": [ { "explain": { "selectTopNode": { "groupNode": { "groupByFields": [ "age", "verified" ], "childSelects": [ { "collectionName": "author", "filter": { "age": { "_gt": 63 } }, "docKeys": null, "groupBy": null, "limit": null, "orderBy": null } ], "selectNode": { "filter": null, "scanNode": { "collectionID": "3", "collectionName": "author", "filter": null, "spans": [ { "end": "/4", "start": "/3" } ] } } } } } } ] } ```
Relevant issue(s)
Resolves #525
For Reviewer(s):
simple
@explain
feature (with the exception oftopLevelNode
).v0.3.0
release.Description
groupNode
explainable.groupNode
.groupBy
is on.groupNode
explanations.Demo
Limitations
groupNode
combined withcount
andsum
aggregates as they would be similar to the graph created by theaverage
groupBy
case (but without theaverageNode
ofcourse).typeIndexJoin
s underparallelNode
#640 is fixed.Tasks
How has this been tested?
Locally with unit tests + Altair + CI
Specify the platform(s) on which this was tested: