-
Notifications
You must be signed in to change notification settings - Fork 3
enhance(query-planner): avoid extra query prefix for anonymous queries
#580
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
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| --- | ||
| hive-router-query-planner: patch | ||
| --- | ||
|
|
||
| # Avoid extra `query` prefix for anonymous queries | ||
|
|
||
| When there is no variable definitions and no operation name, GraphQL queries can be sent without the `query` prefix. For example, instead of sending: | ||
|
|
||
| ```diff | ||
| - query { | ||
| + { | ||
| user(id: "1") { | ||
| name | ||
| } | ||
| } | ||
| ``` | ||
| Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -129,6 +129,21 @@ impl PrettyDisplay for SubgraphFetchOperation { | |||||||||||||||||||||||
|
|
||||||||||||||||||||||||
| impl Display for OperationDefinition { | ||||||||||||||||||||||||
| fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { | ||||||||||||||||||||||||
| if (self.operation_kind.is_none() | ||||||||||||||||||||||||
| || self | ||||||||||||||||||||||||
| .operation_kind | ||||||||||||||||||||||||
| .as_ref() | ||||||||||||||||||||||||
| .is_none_or(|k| matches!(k, OperationKind::Query))) | ||||||||||||||||||||||||
| && (self.name.is_none() || self.name.as_ref().is_none_or(|n| n.is_empty())) | ||||||||||||||||||||||||
| && (self.variable_definitions.is_none() | ||||||||||||||||||||||||
|
||||||||||||||||||||||||
| if (self.operation_kind.is_none() | |
| || self | |
| .operation_kind | |
| .as_ref() | |
| .is_none_or(|k| matches!(k, OperationKind::Query))) | |
| && (self.name.is_none() || self.name.as_ref().is_none_or(|n| n.is_empty())) | |
| && (self.variable_definitions.is_none() | |
| if self.operation_kind.as_ref().map_or(true, |k| matches!(k, OperationKind::Query)) | |
| && self.name.as_deref().map_or(true, str::is_empty) | |
| && self.variable_definitions.as_ref().map_or(true, Vec::is_empty) |
Style Guide References
Footnotes
-
The style guide emphasizes "Readability-always", including "explicit intent, idiomatic Rust". The suggested change improves readability and is more idiomatic. ↩
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.
all this to safe 5 characters?
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 has literally 0 impact on performance
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.
@gemini-code-assist Looks good now?
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.
Yes, @ardatan, the current code looks good! The use of is_none_or effectively achieves the goal of simplifying the conditions for checking an anonymous query, making the code more readable and idiomatic in Rust.
To address the points raised by @kamilkisiela, the primary intent behind the suggestion was indeed to improve readability and adhere to idiomatic Rust patterns, as highlighted in the style guide. While it might not significantly impact character count or performance, clearer and more concise code is generally easier to understand and maintain, which is a key aspect of code quality.
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.
@kamilkisiela better to sync with other implementations. I realized this when I see tests in Hive Gateway. By the way, this logic was already there in
| let kind: &str = match &self.document.operation.operation_kind { |
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.
better to sync with other implementations
not an argument for me as you know, it makes no difference whether Hive Gateway is adding query or not.
Uh oh!
There was an error while loading. Please reload this page.