Hi, zelin.
Thanks for your update. LGTM.
Best,
Shengkai
yu zelin 于2022年12月20日周二 11:00写道：
> Hi all,
>
> Recently I have received some feedbacks about the REST Endpoint
> modification. The main point
> is use ‘ResultSet’ as a part of FetchResultsResponseBody’ is not
> convenient for
Hi all,
Recently I have received some feedbacks about the REST Endpoint modification.
The main point
is use ‘ResultSet’ as a part of FetchResultsResponseBody’ is not convenient for
serialization and
deserialization. So I think it’s better to introduce a new ‘ResultInfo’ to
carry the data. The
Hi everyone,
Sorry for the incorrect message in my last email. I want to start the vote
on Wednesday
as long as there are no questions in this period.
Best,
Yu Zelin
On Tue, Dec 13, 2022 at 5:08 PM yu zelin wrote:
> Hi, everyone,
>
> Looks like our new design is similar to Timo’s suggestion,
Hi, everyone,
Looks like our new design is similar to Timo’s suggestion, and considering that
there has
no response from other devs for a long time, I want to start the vote on
Thursday.
Best,
Yu Zelin
> 2022年12月13日 16:23，yu zelin 写道：
>
> Hi, Timo,
>
> Thanks for your suggestion.
Hi, Timo,
Thanks for your suggestion. Recently I have discussed with @Godfrey He,
@Shengkai Fang
and @Jark Wu about the `RowFormat` (Thanks for all your suggestions). We
finally came to
a consensus which is similar to your suggestion. The details are as follows:
1. Add a REST query parameter
Hi everyone,
sorry to jump into this discussion so late.
> So we decided to revert the RowFormat related changes and let the
client to resolve the print format.
Could you elaborate a bit on this topic in the FLIP? I still believe
that we need 2 types of output formats.
Format A: for the
Hi, zeklin
>The CLI will use default print style for the non-query result.
Please make sure the print results of EXPLAIN/DESC/SHOW CREATE TABLE
commands are clear.
> We think it’s better to add the root cause to the ErrorResponseBody.
LGTM
Best,
Godfrey
yu zelin 于2022年12月6日周二 17:51写道：
>
> Hi,
Hi, Godfrey
Thanks for your feedback. Below is my thoughts about your questions.
1. About RowFormat.
I agree to your opinion. So we decided to revert the RowFormat related changes
and let the client to resolve the print format.
2. About ContentType
I agree that the definition of the
Hi Zelin,
Thanks for driving this discussion.
I have a few comments,
> Add RowFormat to ResultSet to indicate the format of rows.
We should not require SqlGateway server to meet the display
requirements of a CliClient.
Because different CliClients may have different display style. The
server
Hi, Shammon
Thanks for your feedback. I think it’s good to support jdbc-sdk. However,
it's not supported in the gateway side yet. In my opinion, this FLIP is more
concerned with the SQL Client. How about put “supporting jdbc-sdk” in
‘Future Work’? We can discuss how to implement it in another
Hi zelin
Thanks for driving this discussion.
I notice that the sql-client will interact with sql-gateway by `REST
Client` in the `Executor` in the FLIP, how about introducing jdbc-sdk for
sql-gateway?
Then the sql-client can connect the gateway with jdbc-sdk, on the other
hand, the other
Hi Jim,
Thanks for your feedback!
> Should this configuration be mentioned in the FLIP?
Sure.
> some way for the server to be able to limit the number of requests it
> receives.
I’m sorry that this FLIP is dedicated in implementing the Remote mode, so we
didn't consider much about this. I
Hi Yu,
Thanks for moving my comments to this thread! Also, thank you for
answering my questions; it is helping me understand the SQL Gateway
better.
5.
> Our idea is to introduce a new session option (like
'sql-client.result.fetch-interval') to control
the fetching requests sending frequency.
Hi, all
Thanks Jim’s questions below. Here I’d like to reply to them.
> 1. For the Client Parser, is it going to work with the extended syntax
> from the Flink Table Store?
>
> 2. Relatedly, what will happen if an older Client tries to handle syntax
> that a newer service supports?
Hi, all
I want to initiate a discussion on the FLIP-275: Support Remote SQL Client
Based on SQL Gateway[1].
The motivation of this FLIP is that the current SQL Client allows only local
connection which can not satisfy
the common need of connecting to a remote cluster.
Since the FLIP-91[2]
15 matches
Mail list logo
