-
Notifications
You must be signed in to change notification settings - Fork 67
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
Add parsing error message field to TrinoQueryProperties #497
base: main
Are you sure you want to change the base?
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.
(x) Release notes are required, with the following suggested text:
- Add parsing error message field to TrinoQueryProperties
Why do we need to mention this change in a release note?
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java
Outdated
Show resolved
Hide resolved
Thought there might be some people like me who would need the error info. |
a6024fd
to
b8f035a
Compare
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java
Outdated
Show resolved
Hide resolved
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java
Outdated
Show resolved
Hide resolved
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java
Outdated
Show resolved
Hide resolved
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java
Outdated
Show resolved
Hide resolved
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java
Outdated
Show resolved
Hide resolved
@@ -97,6 +97,7 @@ public class TrinoQueryProperties | |||
private Set<String> catalogSchemas = ImmutableSet.of(); | |||
private boolean isNewQuerySubmission; | |||
private boolean isQueryParsingSuccessful; | |||
private Optional<String> parseErrorMessage; |
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.
Why do we need both isQueryParsingSuccessful and parseErrorMessage variables? Is it possible to remove isQueryParsingSuccessful and return the value by checking the size of parseErrorMessage on the fly?
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.
So if there isn't an errorMessage than it is considered successful?
Hmm.. I prefer having a separate variable. @willmostly any thoughts?
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.
When does isQueryParsingSuccessful become true when parseErrorMessage is present?
When does isQueryParsingSuccessful become false when parseErrorMessage is empty?
Having two variables is troublesome as it's easy to miss updating another one. Why do you prefer having a separate variable?
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.
Nowadays am used to using Golang as it always has error field to check before doing any further actions.
Quite convenient should i say.
But am ok with just having error message and removing boolean 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.
Exposing two fields is fine. It's convenient for users. My question was why we need to manage both isQueryParsingSuccessful
and parseErrorMessage
internally instead of the following:
public boolean isQueryParsingSuccessful()
{
return errorMessage.isEmpty();
}
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.
Any ideas on handling this? because when i do this
@JsonProperty("isQueryParsingSuccessful")
public boolean isQueryParsingSuccessful()
{
return errorMessage.isEmpty();
}
I get this error. As of now, isQueryParsingSuccessful is assigned but never accessed.
There is no need to access the field in code, but i don't see any other better ways than simply adding @SuppressWarnings("unused")
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java:99:21
java: [UnusedVariable] The field 'isQueryParsingSuccessful' is never read.
b8f035a
to
e3ba5ed
Compare
e3ba5ed
to
1e2e607
Compare
@ebyhr Thanks for feedback. I think i've finished addressing your points. PTAL :) |
gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java
Outdated
Show resolved
Hide resolved
@@ -97,6 +97,7 @@ public class TrinoQueryProperties | |||
private Set<String> catalogSchemas = ImmutableSet.of(); | |||
private boolean isNewQuerySubmission; | |||
private boolean isQueryParsingSuccessful; | |||
private Optional<String> parseErrorMessage; |
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.
Exposing two fields is fine. It's convenient for users. My question was why we need to manage both isQueryParsingSuccessful
and parseErrorMessage
internally instead of the following:
public boolean isQueryParsingSuccessful()
{
return errorMessage.isEmpty();
}
@@ -53,6 +54,7 @@ void testJsonCreator() | |||
assertThat(deserializedTrinoQueryProperties.getCatalogs()).isEqualTo(trinoQueryProperties.getCatalogs()); | |||
assertThat(deserializedTrinoQueryProperties.getCatalogSchemas()).isEqualTo(trinoQueryProperties.getCatalogSchemas()); | |||
assertThat(deserializedTrinoQueryProperties.isNewQuerySubmission()).isEqualTo(trinoQueryProperties.isNewQuerySubmission()); | |||
assertThat(deserializedTrinoQueryProperties.isQueryParsingSuccessful()).isEqualTo(trinoQueryProperties.isQueryParsingSuccessful()); | |||
assertThat(deserializedTrinoQueryProperties.isQueryParsingSuccessful()).isEqualTo(trinoQueryProperties.isQueryParsingSuccessful());; |
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.
assertThat(deserializedTrinoQueryProperties.isQueryParsingSuccessful()).isEqualTo(trinoQueryProperties.isQueryParsingSuccessful());; | |
assertThat(deserializedTrinoQueryProperties.isQueryParsingSuccessful()).isEqualTo(trinoQueryProperties.isQueryParsingSuccessful()); |
@@ -114,7 +116,8 @@ public TrinoQueryProperties( | |||
@JsonProperty("schemas") Set<String> schemas, | |||
@JsonProperty("catalogSchemas") Set<String> catalogSchemas, | |||
@JsonProperty("isNewQuerySubmission") boolean isNewQuerySubmission, | |||
@JsonProperty("isQueryParsingSuccessful") boolean isQueryParsingSuccessful) | |||
@JsonProperty("isQueryParsingSuccessful") boolean isQueryParsingSuccessful, |
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.
Why do we still need this field? I thought just having the getter is sufficient.
Description
Add a field (private Optional ParseErrorMessage) to TrinoQueryProperties class that stores
e.getMessage()
when there is error.https://github.com/trinodb/trino-gateway/blob/main/gateway-ha/src/main/java/io/trino/gateway/ha/router/TrinoQueryProperties.java#L213-L224
We have server connected with gateway that runs explain before actually running the query.
But not all queries need to be sent with explain.
For example there are cases where queries with parsing failure (no need to run explain cause it is highly likely to fail anyway due to syntax error)
Release notes
(x) This is not user-visible or is docs only, and no release notes are required.