+1 to Timo's proposal. Timo Walther <[email protected]>于2019年3月21日 周四21:40写道：
> 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 > > > > -- Best, Kurt
