Hi everyone,
I also tried to summarize the previous discussion and would add an
additional `Ecosystem` component. I would suggest:
Table SQL / API
Table SQL / Client
Table SQL / Legacy Planner
Table SQL / Planner
Table SQL / Runtime
Table SQL / Ecosystem (such as table connectors, formats, Hive catalog etc.)
This should make everyone happy, no?
Thanks for proosing this Aljoscha. Big +1.
Regards,
Timo
Am 21.03.19 um 14:31 schrieb Aljoscha Krettek:
Cool, I like this. I have one last suggestion. How about this:
Table SQL / API
Table SQL / Client
Table SQL / Classic Planner (or Legacy Planner): Flink Table SQL runtime and
plan translation.
Table SQL / Planner: plan-related for new Blink-based Table SQL runner.
Table SQL / Runtime: runtime-related for new Blink-based Table SQL runner.
It’s Jark’s version but I renamed "Table SQL / Operators" to “Table SQL /
Runtime", because it is not only operators but all the supporting code around that which
is needed at, well, runtime. ;-)
What do you think?
Best,
Aljoscha
On 21. Mar 2019, at 03:52, Jark Wu <[email protected]> wrote:
+1 to Kurt's proposal which removes the "API" prefix and add a table's operator
component.
In the other hand, I think it's worth to distinguish Blink SQL issues and
Flink SQL issues via the component name. Currently, it's hard to distinguish.
How about:
Table SQL / API
Table SQL / Client
Table SQL / Legacy Planner: Flink Table SQL runtime and plan translation.
Table SQL / New Planner: plan-related for new Blink-based Table SQL runner.
Table SQL / Operators: runtime-related for new Blink-based Table SQL runner.
Once blink merge is done, we can combine "Table SQL / Legacy Planner" and "Table SQL /
New Planner" into Table SQL / Planner".
Best,
Jark
On Thu, 21 Mar 2019 at 10:21, Kurt Young <[email protected]
<mailto:[email protected]>> wrote:
Hi Aljoscha,
+1 to further separate table-relate jira components, but I would prefer to
move "Runtime / Operators" to a dedicated "Table SQL / Operators".
There is one concern about the "classic planner" and "new planner", the
naming will be inaccurate after blink merge done and we deprecated classic
planner later (if it happens).
If only one planner left, then what component should we use when creating
jira?
How about this:
Table SQL / API
Table SQL / Client
Table SQL / Planner
Table SQL / Operators
Best,
Kurt
On Thu, Mar 21, 2019 at 12:39 AM Aljoscha Krettek <[email protected]
<mailto:[email protected]>>
wrote:
Hi,
First of all, I hope I cc’ed all the relevant people. Sorry if I forgot
anyone.
I would like to restructure the Table/SQL-related Jira components a bit
more to better reflect the current state of components. Right now we have:
* API / Table SQL: this is just a wild collection of table-related things
* Runtime / Operators: this has general operators stuff, but also new
Blink-based Table operator stuff and maybe classic Table runner stuff
* SQL / Client: as it says
* SQL / Planner: this has issues for the existing classic Flink Table
runner and new things related to merging of the new Blink-based Table Runner
I would suggest to reorganise it like this:
* API / Table SQL: API-related things
* API / Table SQL / Client: the SQL client
* API / Table SQL / Classic Planner: things related to classic Flink Table
API runtime and plan translation, everything to do with execution
* API / Table SQL / New Planner: runtime operators, translation,
everything really, for the new Blink-based Table API/SQL runner
Runtime / Operators would be used purely for non-table-related
operator/runtime stuff.
What do you think? “Classic Planner” and “New Planner” are up for
discussion. 😅 We could even get rid of the API prefix, it doesn’t really
do much, I think.
Best,
Aljoscha
