Hi Shengkai,
thanks for updating the FLIP.
I have one last comment for the option `table.execution.mode`. Should we
already use the global Flink option `execution.runtime-mode` instead?
We are using Flink's options where possible (e.g. `pipeline.name` and
`parallism.default`) why not also for batch/streaming mode?
The description of the option matches to the Blink planner behavior:
```
Among other things, this controls task scheduling, network shuffle
behavior, and time semantics.
```
Regards,
Timo
On 10.02.21 06:30, Shengkai Fang wrote:
Hi, guys.
I have updated the FLIP. It seems we have reached agreement. Maybe we can
start the vote soon. If anyone has other questions, please leave your
comments.
Best，
Shengkai
Rui Li <lirui.fu...@gmail.com>于2021年2月9日 周二下午7:52写道：
Hi guys,
The conclusion sounds good to me.
On Tue, Feb 9, 2021 at 5:39 PM Shengkai Fang <fskm...@gmail.com> wrote:
Hi, Timo, Jark.
I am fine with the new option name.
Best,
Shengkai
Timo Walther <twal...@apache.org>于2021年2月9日 周二下午5:35写道：
Yes, `TableEnvironment#executeMultiSql()` can be future work.
@Rui, Shengkai: Are you also fine with this conclusion?
Thanks,
Timo
On 09.02.21 10:14, Jark Wu wrote:
I'm fine with `table.multi-dml-sync`.
My previous concern about "multi" is that DML in CLI looks like
single
statement.
But we can treat CLI as a multi-line accepting statements from
opening
to
closing.
Thus, I'm fine with `table.multi-dml-sync`.
So the conclusion is `table.multi-dml-sync` (false by default), and
we
will
support this config
in SQL CLI first, will support it in
TableEnvironment#executeMultiSql()
in
the future, right?
Best,
Jark
On Tue, 9 Feb 2021 at 16:37, Timo Walther <twal...@apache.org>
wrote:
Hi everyone,
I understand Rui's concerns. `table.dml-sync` should not apply to
regular `executeSql`. Actually, this option makes only sense when
executing multi statements. Once we have a
`TableEnvironment.executeMultiSql()` this config could be
considered.
Maybe we can find a better generic name? Other platforms will also
need
to have this config option, which is why I would like to avoid a SQL
Client specific option. Otherwise every platform has to come up with
this important config option separately.
Maybe `table.multi-dml-sync` `table.multi-stmt-sync`? Or other
opinions?
Regards,
Timo
On 09.02.21 08:50, Shengkai Fang wrote:
Hi, all.
I think it may cause user confused. The main problem is we have no
means
to detect the conflict configuration, e.g. users set the option
true
and
use `TableResult#await` together.
Best,
Shengkai.
--
Best regards!
Rui Li
