fix: pull queries available on /query rest & ws endpoint
#3820
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fixes: confluentinc#3672 by providing alternative way of issuing pull queries that does NOT log Makes pull queries available on the `/query` RESTful and Websocket endpoints, in the same way that push queries are. Note: this change does not _remove_ pull query support from the `/ksql` endpoint, nor does it switch the CLI over to use the `/query` endpoint. The CLI continues to use the `/ksql` endpoint for pull queries. Push and pull queries to the `/query` rest endpoint now return the schema of the rows in the first message. This is required as the 'DESCRIBE' that CLI was previously running to get column headers doesn't work for pull queries yet. (Known issue: confluentinc#3495). This is similar to the pattern used by the websocket endpoint, which also sends the schema in the first message. In addition, I've hidden null fields and added a 'header' row to return the schema of the data. The output now looks like: ```json [{"header":{"queryId":"someId","schema":"`USERID` STRING, `PAGEID` STRING, `VIEWTIME` BIGINT, `ROWKEY` STRING"}}, {"row":{"columns":["USER_1","PAGE_1",1,"1"]}}, {"row":{"columns":["USER_2","PAGE_2",2,"2"]}}, {"finalMessage":"Limit Reached"}]" ``` BREAKING CHANGE: the response from the RESTful API for push queries has changed: it now returns a line with the schema and query id in a `header` field and null fields are not included in the payload. The CLI is backwards compatible with older versions of the server, though it won't output column headings from older versions.
vpapavas
approved these changes
Nov 12, 2019
vpapavas
reviewed
Nov 12, 2019
| output.write("\n".getBytes(StandardCharsets.UTF_8)); | ||
| output.flush(); | ||
| } | ||
|
|
||
| private StreamedRow buildHeader() { | ||
| // Push queries only return value columns, but query metadata schema includes key and meta: |
There was a problem hiding this comment.
With the comment, you mean you want the schema to only contain the value columns, but currently they return also the meta columns and that's what you are working on fixing?
There was a problem hiding this comment.
Nope. The schema in the query metadata contains key and meta columns. But push queries only return value columns. Hence in this method I create a new schema with only the value columns.
The longer term fix is to store the right schema in the query metadata, but that's outside the scope of this PR.
The outstanding issue with schemas is for pull queries, not push. Pull queries return key columns, but the returned schema currently doesn't include this.
2 tasks
vinothchandar
approved these changes
Nov 12, 2019
| @@ -316,18 +314,6 @@ private void handleStreamedQuery( | |||
| final String query, | |||
| final SqlBaseParser.QueryStatementContext ignored | |||
| ) { | |||
| final RestResponse<KsqlEntityList> explainResponse = restClient | |||
There was a problem hiding this comment.
Once we have #3495 , is the plan to introduce some header to control whether schema is part of the response or not? It may make sense for CLI to request the schema always, it may add a constant overhead for queries from real applications.?
There was a problem hiding this comment.
yeah parameter makes sense.
|
test this please |
|
retest this please |
|
I rekicked it and it still failed with checkstyle |
big-andy-coates
added a commit
that referenced
this pull request
Nov 14, 2019
* fix: pull queries available on `/query` rest & ws endpoint fixes: #3672 by providing alternative way of issuing pull queries that does NOT log Makes pull queries available on the `/query` RESTful and Websocket endpoints, in the same way that push queries are. Note: this change does not _remove_ pull query support from the `/ksql` endpoint, nor does it switch the CLI over to use the `/query` endpoint. The CLI continues to use the `/ksql` endpoint for pull queries. Push and pull queries to the `/query` rest endpoint now return the schema of the rows in the first message. This is required as the 'DESCRIBE' that CLI was previously running to get column headers doesn't work for pull queries yet. (Known issue: #3495). This is similar to the pattern used by the websocket endpoint, which also sends the schema in the first message. In addition, I've hidden null fields and added a 'header' row to return the schema of the data. The output now looks like: ```json [{"header":{"queryId":"someId","schema":"`USERID` STRING, `PAGEID` STRING, `VIEWTIME` BIGINT, `ROWKEY` STRING"}}, {"row":{"columns":["USER_1","PAGE_1",1,"1"]}}, {"row":{"columns":["USER_2","PAGE_2",2,"2"]}}, {"finalMessage":"Limit Reached"}]" ``` BREAKING CHANGE: the response from the RESTful API for push queries has changed: it now returns a line with the schema and query id in a `header` field and null fields are not included in the payload. The CLI is backwards compatible with older versions of the server, though it won't output column headings from older versions. (cherry picked from commit e2321f5)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
fixes: #3672 by providing alternative way of issuing pull queries that does NOT log
fixes: #3806
We should look to include #3819 as part of this fix.
Makes pull queries available on the
/queryRESTful and Websocket endpoints, in the same way that push queries are.Note: this change does not remove pull query support from the
/ksqlendpoint, nor does it switch the CLI over to usethe
/queryendpoint. The CLI continues to use the/ksqlendpoint for pull queries.Push and pull queries to the
/queryrest endpoint now return the schema of the rows in the first message.This is required as the 'DESCRIBE' that CLI was previously running to get column headers doesn't work for pull queries yet. (Known issue: #3495).
This is similar to the pattern used by the websocket endpoint, which also sends the schema in the first message.
In addition, I've hidden null fields and added a 'header' row to return the schema of the data. The output now looks like:
{"header":{"queryId":"someId","schema":"`USERID` STRING, `PAGEID` STRING, `VIEWTIME` BIGINT, `ROWKEY` STRING"}} {"row":{"columns":["USER_1","PAGE_1",1,"1"]}} {"row":{"columns":["USER_2","PAGE_2",2,"2"]}} {"finalMessage":"Limit Reached"}"Note: With this PR the payload from the rest endpoint continues to be invalid JSON, just like it is for push queries. #3819 addresses this.
BREAKING CHANGE: the response from the RESTful API for push queries has changed: it now returns a line with the schema and query id in a
headerfield and null fields are not included in the payload.The CLI is backwards compatible with older versions of the server, though it won't output column headings from older versions.
Note: This PR does NOT address issue #3663. At the moment I have a feeling an admin client is still made per-request.
Outstanding tasks:
/queryendpoint./ksqlendpoint.Testing done
Lots of testing, including manual
Reviewer checklist