+1 to Timo's proposal. Best, Jark
On Fri, 22 Mar 2019 at 07:42, Kurt Young <ykt...@gmail.com> wrote: > +1 to Timo's proposal. > > Timo Walther <twal...@apache.org>于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 <imj...@gmail.com> 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 <ykt...@gmail.com <mailto: > > ykt...@gmail.com>> 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 < > aljos...@apache.org > > <mailto:aljos...@apache.org>> > > >> 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 >
