Skip to content
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: Rename aggregate gql types #638

Merged
merged 13 commits into from
Jul 18, 2022
Merged

Conversation

AndrewSisley
Copy link
Contributor

Relevant issue(s)

Resolves #377, #574

Description

Adds schema tests for aggregates. Orders schema input type and args (gql-go version update). Fixes a bunch of issues in generate.go. Renames aggregate gql types.

Suggest reviewing commit by commit, there are a few semi-related changes in this PR (each should have it's own commit+description).

Tasks

  • I made sure the code is well commented, particularly hard-to-understand areas.
  • I made sure the repository-held documentation is changed accordingly.
  • I made sure the pull request title adheres to the conventional commit style (the subset used in the project can be found in tools/configs/chglog/config.yml).
  • I made sure to discuss its limitations such as threats to validity, vulnerability to mistake and misuse, robustness to invalidation of assumptions, resource requirements, ...

How has this been tested?

(replace) Describe the tests performed to verify the changes. Provide instructions to reproduce them.

Specify the platform(s) on which this was tested:

  • Debian Linux

@AndrewSisley AndrewSisley added bug Something isn't working documentation Improvements or additions to documentation area/schema Related to the schema system code quality Related to improving code quality action/no-benchmark Skips the action that runs the benchmark. labels Jul 15, 2022
@AndrewSisley AndrewSisley requested a review from a team July 15, 2022 15:37
@AndrewSisley AndrewSisley self-assigned this Jul 15, 2022
@codecov
Copy link

codecov bot commented Jul 15, 2022

Codecov Report

Merging #638 (43eab8e) into develop (f1beb0a) will decrease coverage by 0.06%.
The diff coverage is 83.92%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop     #638      +/-   ##
===========================================
- Coverage    57.15%   57.09%   -0.07%     
===========================================
  Files          122      122              
  Lines        14642    14646       +4     
===========================================
- Hits          8369     8362       -7     
- Misses        5560     5567       +7     
- Partials       713      717       +4     
Impacted Files Coverage Δ
query/graphql/schema/generate.go 84.41% <83.92%> (-0.82%) ⬇️
query/graphql/schema/relations.go 60.82% <0.00%> (-1.55%) ⬇️

@AndrewSisley AndrewSisley force-pushed the sisley/fix/I377-gql-type-names branch from 56c643c to 72e4059 Compare July 15, 2022 15:44
Copy link
Collaborator

@fredcarle fredcarle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just want to confirm, the ContainsData is to make sure the data contains what is defined but not necessarily matching perfectly?

"Failed to append type while generating query type defs from an AST",
err,
)
return nil, err
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

praise: I like this much better.

suggestion (non-blocking): you could keep the message if you think it's relevant.

return nil, fmt.Errorf("failed to append type while generating query type defs from an AST: %w", err)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks - was hiding a few errors that got fixed in this PR lol. I don't recall the extra text being particularly useful

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also don't forget the question I had in my main comment :)

assert.Equal(t, testCase.ExpectedData, resultantData)
}

for k, result := range resultantData {
assert.Equal(t, testCase.ExpectedData[k], result)
if len(testCase.ExpectedData) == 0 && len(testCase.ContainsData) > 0 {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thought: perhaps else if?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would make sense but these two can never be true at the same time so it won't change much other than visual flow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point, just feel like with an else if you don't even have to bother reading the checks to worry if it will go inside the other condition (by definition of else if).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whilst the logic here fits an if-else, they are different concepts IMO and I prefer to keep the independent

)
if err != nil {
log.ErrorE(ctx, "Error while registering single relation", err)
if !gql.IsLeafType(ltype) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: limit scope of ltype.

Suggested change
if !gql.IsLeafType(ltype) {
if ltype := subobj.OfType; !gql.IsLeafType(ltype) {

nitpick: Also would like to rename ltype to lType (similar to fType).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think this makes sense.

Copy link
Contributor Author

@AndrewSisley AndrewSisley Jul 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is out of scope, and whilst it would be quick to change, I do not wish to encourage further requests of this nature in PRs

EDIT: I missed the scope-limit request of your comment, mine reply was to the rename only. RE scope I dont think it matters much at all, and isn't worth tweaking the branch for this alone. (Plus if I edit this, it will be to remove the variable entirely, not to just shrink it's scope)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO is a fairly quick thing and better code. Non-blocking though so giving approval.

Comment on lines +829 to +833
return fmt.Sprintf("%s__%s__%s", hostName, fieldName, "CountSelector")
}

func genObjectCountName(hostName string) string {
return fmt.Sprintf("%s__%s", hostName, "CountSelector")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: does "CountSelector" need to be commonly shared? if so perhaps a const.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is only used in these two functions, and should never have need to be referenced elsewhere (e.g. in planner/etc). Leaving as is

@AndrewSisley
Copy link
Contributor Author

Just want to confirm, the ContainsData is to make sure the data contains what is defined but not necessarily matching perfectly?

The stuff in ContainsData has to match exactly, but it does not need to include everything (so e.g. the tests dont have to specify every field on an object)

Copy link
Member

@shahzadlone shahzadlone left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, would still like the changes I requested (but non-blocking).

It errored, logged and continued
New version yields input fields and args in a deterministic order
Allows asserting that specific items exist, without forcing the tests to define all expected values (costing dev time and coupling the test to unrelated functionality).
Double underscore added as a seperator (reduces risk of name collisions). Removed naming suffix differences between inline-array and other fields. New suffix chosen.  Casing corrected (left as user-defined, Title casing was lower casing inner values, and reduces risk of collisions (e.g. users vs Users)).
@AndrewSisley AndrewSisley force-pushed the sisley/fix/I377-gql-type-names branch from 72e4059 to 43eab8e Compare July 18, 2022 13:45
@AndrewSisley AndrewSisley merged commit ddab2cc into develop Jul 18, 2022
@AndrewSisley AndrewSisley deleted the sisley/fix/I377-gql-type-names branch July 18, 2022 13:57
shahzadlone pushed a commit to shahzadlone/defradb that referenced this pull request Feb 23, 2024
* Dont register inline arrays as relationships

It errored, logged and continued

* Dont try and generate filter blocks for inline arrays

* Don't generate filters for objects with no fields

Will error

* Dont append filter base arg if already exists

* Check filter is permitted before adding it

* Return error instead of logging and continuing

* Update gql-go version

New version yields input fields and args in a deterministic order

* Go mod tidy

* Add contains capactiy to schema tests

Allows asserting that specific items exist, without forcing the tests to define all expected values (costing dev time and coupling the test to unrelated functionality).

* Add top-level aggregate schema tests

* Add simple object aggregate schema tests

* Add inline array aggregate schema tests

* Rename aggregate selectors

Double underscore added as a seperator (reduces risk of name collisions). Removed naming suffix differences between inline-array and other fields. New suffix chosen.  Casing corrected (left as user-defined, Title casing was lower casing inner values, and reduces risk of collisions (e.g. users vs Users)).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
action/no-benchmark Skips the action that runs the benchmark. area/schema Related to the schema system bug Something isn't working code quality Related to improving code quality documentation Improvements or additions to documentation
Projects
None yet
3 participants