Thanks Jane for the summary. Looks good to me. On Wed, Feb 3, 2021 at 7:53 PM Jane Chan <qingyue....@gmail.com> wrote:
> Hi @Jark, @Timo, I've updated the comments, and please have a look when > you're free. > > Best, > Jane > > On Wed, Feb 3, 2021 at 7:14 PM Jane Chan <qingyue....@gmail.com> wrote: > > > > > Reply @Timo > > > >> Remove the `used` column for SHOW MODULES. It will always show true. > >> > > Good catch. It's a copy-paste typo, and I forgot to remove that column. > > > > How about creating a POJO (static inner class of ModuleManager) called > >> `ModuleEntry` or similar. > >> > > +1 for better encapsulation. > > > > Reply @Jark > > > >> A minor comment on `useModules(List<String> names)`, would be better to > >> use varargs here to a more fluent API: `useModules("a", "b", "c")`. > >> > > +1, and that's better. > > > > Do we also need to add these new methods (useModules, listFullModules) > >> to TableEnvironment? > >> > > Yes, indeed. > > > > Thank you all for polishing this proposal to make it more thorough. > > > > Best, > > Jane > > > > On Wed, Feb 3, 2021 at 6:41 PM Jark Wu <imj...@gmail.com> wrote: > > > >> A minor comment on `useModules(List<String> names)`, > >> would be better to use varargs here to a more fluent API: > `useModules("a", > >> "b", "c")`. > >> > >> Besides, do we also need to add these new methods (useModules, > >> listFullModules) to > >> TableEnvironment? > >> > >> Best, > >> Jark > >> > >> On Wed, 3 Feb 2021 at 18:36, Timo Walther <twal...@apache.org> wrote: > >> > >> > Thanks for the nice summary Jane. The summary looks great. Some minor > >> > feedback: > >> > > >> > - Remove the `used` column for SHOW MODULES. It will always show true. > >> > > >> > - `List<Pair<String, Boolean>> listFullModules()` is a very long > >> > signature. And `Pair` should be avoided in code because it is not very > >> > descriptive. How about creating a POJO (static inner class of > >> > ModuleManager) called `ModuleEntry` or similar. > >> > > >> > Otherwise +1 for the proposal. > >> > > >> > Regards, > >> > Timo > >> > > >> > On 03.02.21 11:24, Jane Chan wrote: > >> > > Hi everyone, > >> > > > >> > > I did a summary on the Jira issue page [1] since the discussion has > >> > > achieved a consensus. If there is anything missed or not corrected, > >> > please > >> > > let me know. > >> > > > >> > > [1] https://issues.apache.org/jira/browse/FLINK-21045# > >> > > > >> > > Best, > >> > > Jane > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > On Wed, Feb 3, 2021 at 1:33 PM Jark Wu <imj...@gmail.com> wrote: > >> > > > >> > >> Hi Jane, > >> > >> > >> > >> Yes. I think we should fail fast. > >> > >> > >> > >> Best, > >> > >> Jark > >> > >> > >> > >> On Wed, 3 Feb 2021 at 12:06, Jane Chan <qingyue....@gmail.com> > >> wrote: > >> > >> > >> > >>> Hi everyone, > >> > >>> > >> > >>> Thanks for the discussion to make this improvement plan clearer. > >> > >>> > >> > >>> Hi, @Jark, @Rui, and @Timo, I'm collecting the final discussion > >> > summaries > >> > >>> now and want to confirm one thing that for the statement `USE > >> MODULES x > >> > >> [, > >> > >>> y, z, ...]`, if the module name list contains an unexsited module, > >> > shall > >> > >> we > >> > >>> #1 fail the execution for all of them or #2 enabled the rest > modules > >> > and > >> > >>> return a warning to users? My personal preference goes to #1 for > >> > >>> simplicity. What do you think? > >> > >>> > >> > >>> Best, > >> > >>> Jane > >> > >>> > >> > >>> On Tue, Feb 2, 2021 at 3:53 PM Timo Walther <twal...@apache.org> > >> > wrote: > >> > >>> > >> > >>>> +1 > >> > >>>> > >> > >>>> @Jane Can you summarize our discussion in the JIRA issue? > >> > >>>> > >> > >>>> Thanks, > >> > >>>> Timo > >> > >>>> > >> > >>>> > >> > >>>> On 02.02.21 03:50, Jark Wu wrote: > >> > >>>>> Hi Timo, > >> > >>>>> > >> > >>>>>> Another question is whether a LOAD operation also adds the > >> module to > >> > >>> the > >> > >>>>> enabled list by default? > >> > >>>>> > >> > >>>>> I would like to add the module to the enabled list by default, > the > >> > >> main > >> > >>>>> reasons are: > >> > >>>>> 1) Reordering is an advanced requirement, adding modules needs > >> > >>> additional > >> > >>>>> USE statements with "core" module > >> > >>>>> sounds too burdensome. Most users should be satisfied with > only > >> > >> LOAD > >> > >>>>> statements. > >> > >>>>> 2) We should keep compatible for TableEnvironment#loadModule(). > >> > >>>>> 3) We are using the LOAD statement instead of CREATE, so I think > >> it's > >> > >>>> fine > >> > >>>>> that it does some implicit things. > >> > >>>>> > >> > >>>>> Best, > >> > >>>>> Jark > >> > >>>>> > >> > >>>>> On Tue, 2 Feb 2021 at 00:48, Timo Walther <twal...@apache.org> > >> > >> wrote: > >> > >>>>> > >> > >>>>>> Not the module itself but the ModuleManager should handle this > >> case, > >> > >>>> yes. > >> > >>>>>> > >> > >>>>>> Regards, > >> > >>>>>> Timo > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> On 01.02.21 17:35, Jane Chan wrote: > >> > >>>>>>> +1 to Jark's proposal > >> > >>>>>>> > >> > >>>>>>> To make it clearer, will `module#getFunctionDefinition()` > >> > >> return > >> > >>>> empty > >> > >>>>>>> suppose the module is loaded but not enabled? > >> > >>>>>>> > >> > >>>>>>> Best, > >> > >>>>>>> Jane > >> > >>>>>>> > >> > >>>>>>> On Mon, Feb 1, 2021 at 10:02 PM Timo Walther < > >> twal...@apache.org> > >> > >>>> wrote: > >> > >>>>>>> > >> > >>>>>>>> +1 to Jark's proposal > >> > >>>>>>>> > >> > >>>>>>>> I like the difference between just loading and actually > >> enabling > >> > >>> these > >> > >>>>>>>> modules. > >> > >>>>>>>> > >> > >>>>>>>> @Rui: I would use the same behavior as catalogs here. You > >> cannot > >> > >>>> `USE` a > >> > >>>>>>>> catalog without creating it before. > >> > >>>>>>>> > >> > >>>>>>>> Another question is whether a LOAD operation also adds the > >> module > >> > >> to > >> > >>>> the > >> > >>>>>>>> enabled list by default? > >> > >>>>>>>> > >> > >>>>>>>> Regards, > >> > >>>>>>>> Timo > >> > >>>>>>>> > >> > >>>>>>>> On 01.02.21 13:52, Rui Li wrote: > >> > >>>>>>>>> If `USE MODULES` implies unloading modules that are not > >> listed, > >> > >>> does > >> > >>>> it > >> > >>>>>>>>> also imply loading modules that are not previously loaded, > >> > >>> especially > >> > >>>>>>>> since > >> > >>>>>>>>> we're mapping modules by name now? > >> > >>>>>>>>> > >> > >>>>>>>>> On Mon, Feb 1, 2021 at 8:20 PM Jark Wu <imj...@gmail.com> > >> wrote: > >> > >>>>>>>>> > >> > >>>>>>>>>> I agree with Timo that the USE implies the specified > modules > >> are > >> > >>> in > >> > >>>>>> use > >> > >>>>>>>> in > >> > >>>>>>>>>> the specified order and others are not used. > >> > >>>>>>>>>> This would be easier to know what's the result list and > order > >> > >>> after > >> > >>>>>> the > >> > >>>>>>>> USE > >> > >>>>>>>>>> statement. > >> > >>>>>>>>>> That means: if current modules in order are x, y, z. And > `USE > >> > >>>> MODULES > >> > >>>>>>>> z, y` > >> > >>>>>>>>>> means current modules in order are z, y. > >> > >>>>>>>>>> > >> > >>>>>>>>>> But I would like to not unload the unmentioned modules in > the > >> > >> USE > >> > >>>>>>>>>> statement. Because it seems strange that USE > >> > >>>>>>>>>> will implicitly remove modules. In the above example, the > >> user > >> > >> may > >> > >>>>>> type > >> > >>>>>>>> the > >> > >>>>>>>>>> wrong modules list using USE by mistake > >> > >>>>>>>>>> and would like to declare the list again, the user has > >> to > >> > >>> create > >> > >>>>>> the > >> > >>>>>>>>>> module again with some properties he may don't know. > >> Therefore, > >> > >> I > >> > >>>>>>>> propose > >> > >>>>>>>>>> the USE statement just specifies the current module lists > and > >> > >>>> doesn't > >> > >>>>>>>>>> unload modules. > >> > >>>>>>>>>> Besides that, we may need a new syntax to list all the > >> modules > >> > >>>>>> including > >> > >>>>>>>>>> not used but loaded. > >> > >>>>>>>>>> We can introduce SHOW FULL MODULES for this purpose with an > >> > >>>> additional > >> > >>>>>>>>>> `used` column. > >> > >>>>>>>>>> > >> > >>>>>>>>>> For example: > >> > >>>>>>>>>> > >> > >>>>>>>>>> Flink SQL> list modules: > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> | modules | > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> | x | > >> > >>>>>>>>>> | y | > >> > >>>>>>>>>> | z | > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> Flink SQL> USE MODULES z, y; > >> > >>>>>>>>>> Flink SQL> show modules: > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> | modules | > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> | z | > >> > >>>>>>>>>> | y | > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> Flink SQL> show FULL modules; > >> > >>>>>>>>>> ------------------- > >> > >>>>>>>>>> | modules | used | > >> > >>>>>>>>>> ------------------- > >> > >>>>>>>>>> | z | true | > >> > >>>>>>>>>> | y | true | > >> > >>>>>>>>>> | x | false | > >> > >>>>>>>>>> ------------------- > >> > >>>>>>>>>> Flink SQL> USE MODULES z, y, x; > >> > >>>>>>>>>> Flink SQL> show modules; > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> | modules | > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> | z | > >> > >>>>>>>>>> | y | > >> > >>>>>>>>>> | x | > >> > >>>>>>>>>> ----------- > >> > >>>>>>>>>> > >> > >>>>>>>>>> What do you think? > >> > >>>>>>>>>> > >> > >>>>>>>>>> Best, > >> > >>>>>>>>>> Jark > >> > >>>>>>>>>> > >> > >>>>>>>>>> On Mon, 1 Feb 2021 at 19:02, Jane Chan < > >> qingyue....@gmail.com> > >> > >>>> wrote: > >> > >>>>>>>>>> > >> > >>>>>>>>>>> Hi Timo, thanks for the discussion. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> It seems to reach an agreement regarding #3 that <1> > Module > >> > >> name > >> > >>>>>> should > >> > >>>>>>>>>>> better be a simple identifier rather than a string > literal. > >> <2> > >> > >>>>>>>> Property > >> > >>>>>>>>>>> `type` is redundant and should be removed, and mapping > will > >> > >> rely > >> > >>> on > >> > >>>>>> the > >> > >>>>>>>>>>> module name because loading a module multiple times just > >> using > >> > >> a > >> > >>>>>>>>>> different > >> > >>>>>>>>>>> module name doesn't make much sense. <3> We should migrate > >> to > >> > >> the > >> > >>>>>> newer > >> > >>>>>>>>>> API > >> > >>>>>>>>>>> rather than the deprecated `TableFactory` class. > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Regarding #1, I think the point lies in whether changing > the > >> > >>>>>> resolution > >> > >>>>>>>>>>> order implies an `unload` operation explicitly (i.e., > users > >> > >> could > >> > >>>>>> sense > >> > >>>>>>>>>>> it). What do others think? > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> Best, > >> > >>>>>>>>>>> Jane > >> > >>>>>>>>>>> > >> > >>>>>>>>>>> On Mon, Feb 1, 2021 at 6:41 PM Timo Walther < > >> > >> twal...@apache.org> > >> > >>>>>>>> wrote: > >> > >>>>>>>>>>> > >> > >>>>>>>>>>>> IMHO I would rather unload the not mentioned modules. The > >> > >>>> statement > >> > >>>>>>>>>>>> expresses `USE` that implicilty implies that the other > >> modules > >> > >>> are > >> > >>>>>>>> "not > >> > >>>>>>>>>>>> used". What do others think? > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> Regards, > >> > >>>>>>>>>>>> Timo > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> On 01.02.21 11:28, Jane Chan wrote: > >> > >>>>>>>>>>>>> Hi Jark and Rui, > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> Thanks for the discussions. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> Regarding #1, I'm fine with `USE MODULES` syntax, and > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> It can be interpreted as "setting the current order of > >> > >>> modules", > >> > >>>>>>>>>> which > >> > >>>>>>>>>>>> is > >> > >>>>>>>>>>>>>> similar to "setting the current catalog" for `USE > >> CATALOG`. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>> I would like to confirm that the unmentioned modules > >> remain > >> > >> in > >> > >>>> the > >> > >>>>>>>>>> same > >> > >>>>>>>>>>>>> relative order? E.g., if there are three loaded modules > >> `X`, > >> > >>> `Y`, > >> > >>>>>>>>>> `Z`, > >> > >>>>>>>>>>>> then > >> > >>>>>>>>>>>>> `USE MODULES Y, Z` means shifting the order to `Y`, `Z`, > >> `X`. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> Regarding #3, I'm fine with mapping modules purely by > >> name, > >> > >>> and I > >> > >>>>>>>>>> think > >> > >>>>>>>>>>>>> Jark raised a good point on making the module name a > >> simple > >> > >>>>>>>>>> identifier > >> > >>>>>>>>>>>>> instead of a string literal. For backward compatibility, > >> > >> since > >> > >>> we > >> > >>>>>>>>>>> haven't > >> > >>>>>>>>>>>>> supported this syntax yet, the affected users are those > >> who > >> > >>>> defined > >> > >>>>>>>>>>>> modules > >> > >>>>>>>>>>>>> in the YAML configuration file. Maybe we can eliminate > the > >> > >>> 'type' > >> > >>>>>>>>>> from > >> > >>>>>>>>>>>> the > >> > >>>>>>>>>>>>> 'requiredContext' to make it optional. Thus the proposed > >> > >>> mapping > >> > >>>>>>>>>>>> mechanism > >> > >>>>>>>>>>>>> could use the module name to lookup the suitable > factory, > >> > >> and > >> > >>> in > >> > >>>>>> the > >> > >>>>>>>>>>>>> meanwhile updating documentation to encourage users to > >> > >> simplify > >> > >>>>>> their > >> > >>>>>>>>>>>> YAML > >> > >>>>>>>>>>>>> configuration. And in the long run, we can deprecate the > >> > >>> 'type'. > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> Best, > >> > >>>>>>>>>>>>> Jane > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>> On Mon, Feb 1, 2021 at 4:19 PM Rui Li < > >> lirui.fu...@gmail.com > >> > >>> > >> > >>>>>> wrote: > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Thanks Jane for starting the discussion. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Regarding #1, I also prefer `USE MODULES` syntax. It > can > >> be > >> > >>>>>>>>>>> interpreted > >> > >>>>>>>>>>>> as > >> > >>>>>>>>>>>>>> "setting the current order of modules", which is > similar > >> to > >> > >>>>>> "setting > >> > >>>>>>>>>>> the > >> > >>>>>>>>>>>>>> current catalog" for `USE CATALOG`. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> Regarding #3, I'm fine to map modules purely by name > >> > >> because I > >> > >>>>>> think > >> > >>>>>>>>>>> it > >> > >>>>>>>>>>>>>> satisfies all the use cases we have at hand. But I > guess > >> we > >> > >>> need > >> > >>>>>> to > >> > >>>>>>>>>>> make > >> > >>>>>>>>>>>>>> sure we're backward compatible, i.e. users don't need > to > >> > >>> change > >> > >>>>>>>>>> their > >> > >>>>>>>>>>>> yaml > >> > >>>>>>>>>>>>>> files to configure the modules. > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> On Mon, Feb 1, 2021 at 3:10 PM Jark Wu < > imj...@gmail.com > >> > > >> > >>>> wrote: > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Thanks Jane for the summary and starting the > discussion > >> in > >> > >>> the > >> > >>>>>>>>>>> mailing > >> > >>>>>>>>>>>>>>> list. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Here are my thoughts: > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> 1) syntax to reorder modules > >> > >>>>>>>>>>>>>>> I agree with Rui Li it would be quite useful if we can > >> have > >> > >>>> some > >> > >>>>>>>>>>> syntax > >> > >>>>>>>>>>>>>> to > >> > >>>>>>>>>>>>>>> reorder modules. > >> > >>>>>>>>>>>>>>> I slightly prefer `USE MODULES x, y, z` than `RELOAD > >> > >> MODULES > >> > >>> x, > >> > >>>>>> y, > >> > >>>>>>>>>>> z`, > >> > >>>>>>>>>>>>>>> because USE has a more sense of effective and > specifying > >> > >>>>>> ordering, > >> > >>>>>>>>>>> than > >> > >>>>>>>>>>>>>>> RELOAD. > >> > >>>>>>>>>>>>>>> From my feeling, RELOAD just means we unregister > >> and > >> > >>>> register > >> > >>>>>>>>>> x,y,z > >> > >>>>>>>>>>>>>> modules > >> > >>>>>>>>>>>>>>> again, > >> > >>>>>>>>>>>>>>> it sounds like other registered modules are still in > use > >> > >> and > >> > >>> in > >> > >>>>>> the > >> > >>>>>>>>>>>>>> order. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> 3) mapping modules purely by name > >> > >>>>>>>>>>>>>>> This can definitely improve the usability of loading > >> > >> modules, > >> > >>>>>>>>>> because > >> > >>>>>>>>>>>>>>> the 'type=' property > >> > >>>>>>>>>>>>>>> looks really redundant. We can think of this as a > syntax > >> > >>> sugar > >> > >>>>>> that > >> > >>>>>>>>>>> the > >> > >>>>>>>>>>>>>>> default type value is the module name. > >> > >>>>>>>>>>>>>>> And we can support to specify 'type=' property in the > >> > >> future > >> > >>> to > >> > >>>>>>>>>> allow > >> > >>>>>>>>>>>>>>> multiple modules for one module type. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Besides, I would like to mention one more change, that > >> the > >> > >>>> module > >> > >>>>>>>>>>> name > >> > >>>>>>>>>>>>>>> proposed in FLIP-68 is a string literal. > >> > >>>>>>>>>>>>>>> But I think we are all on the same page to change it > >> into a > >> > >>>>>> simple > >> > >>>>>>>>>>>>>>> (non-compound) identifier. > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> LOAD/UNLOAD MODULE 'core' > >> > >>>>>>>>>>>>>>> ==> > >> > >>>>>>>>>>>>>>> LOAD/UNLOAD MODULE core > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> Best, > >> > >>>>>>>>>>>>>>> Jark > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> On Sat, 30 Jan 2021 at 04:00, Jane Chan < > >> > >>> qingyue....@gmail.com > >> > >>>>> > >> > >>>>>>>>>>> wrote: > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> Hi everyone, > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> I would like to start a discussion on FLINK-21045 [1] > >> > >> about > >> > >>>>>>>>>>> supporting > >> > >>>>>>>>>>>>>>>> `LOAD MODULE` and `UNLOAD MODULE` SQL syntax. It's > >> first > >> > >>>>>> proposed > >> > >>>>>>>>>> by > >> > >>>>>>>>>>>>>>>> FLIP-68 [2] as following. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> -- load a module with the given name and append it to > >> the > >> > >>> end > >> > >>>> of > >> > >>>>>>>>>> the > >> > >>>>>>>>>>>>>>> module > >> > >>>>>>>>>>>>>>>> list > >> > >>>>>>>>>>>>>>>> LOAD MODULE 'name' [WITH ('type'='xxx', > >> 'prop'='myProp', > >> > >>> ...)] > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> --unload a module by name from the module list and > >> other > >> > >>>> modules > >> > >>>>>>>>>>>> remain > >> > >>>>>>>>>>>>>>> in > >> > >>>>>>>>>>>>>>>> the same relative positions > >> > >>>>>>>>>>>>>>>> UNLOAD MODULE 'name' > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> After a round of discussion on the Jira ticket, it > >> seems > >> > >>> some > >> > >>>>>>>>>>>>>> unanswered > >> > >>>>>>>>>>>>>>>> questions need more opinions and suggestions. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> 1. The way to redefine resolution order easily > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> Rui Li suggested introducing `USE MODULES` > and > >> > >>> adding > >> > >>>>>>>> similar > >> > >>>>>>>>>>>>>>>> functionality to the API because > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> 1) It's very tedious to unload old modules > just > >> to > >> > >>>> reorder > >> > >>>>>>>>>> them. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> 2) Users may not even know how to "re-load" an > >> old > >> > >>> module > >> > >>>>>> if it > >> > >>>>>>>>>>> was > >> > >>>>>>>>>>>>>> not > >> > >>>>>>>>>>>>>>>>> initially loaded by the user, e.g. don't know which > >> type > >> > >> to > >> > >>>>>> use. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> Jane Chan wondered that module is not like > the > >> > >>> catalog > >> > >>>>>> which > >> > >>>>>>>>>>> has > >> > >>>>>>>>>>>> a > >> > >>>>>>>>>>>>>>>> concept of namespace could specify, and `USE` sounds > >> like > >> > >> a > >> > >>>>>>>>>>>>>>>> mutual-exclusive concept. > >> > >>>>>>>>>>>>>>>> Maybe `RELOAD MODULES` can express upgrading > >> the > >> > >>>>>> priority of > >> > >>>>>>>>>>> the > >> > >>>>>>>>>>>>>>> loaded > >> > >>>>>>>>>>>>>>>> module(s). > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> 2. `LOAD/UNLOAD MODULE` v.s. `CREATE/DROP MODULE` > >> syntax > >> > >>>>>>>>>>>>>>>> Jark Wu and Nicholas Jiang proposed to use > >> > >>>> `CREATE/DROP > >> > >>>>>>>>>> MODULE` > >> > >>>>>>>>>>>>>>> instead > >> > >>>>>>>>>>>>>>>> of `LOAD/UNLOAD MODULE` because > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>>> 1) From a pure SQL user's perspective, maybe > >> > `CREATE > >> > >>>>>> MODULE + > >> > >>>>>>>>>> USE > >> > >>>>>>>>>>>>>>>> MODULE` > >> > >>>>>>>>>>>>>>>>> is easier to use rather than `LOAD/UNLOAD`. > >> > >>>>>>>>>>>>>>>>> 2) This will be very similar to what the > catalog > >> > >> used > >> > >>>> now. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> Timo Walther would rather stick to the agreed > >> > design > >> > >>>>>> because > >> > >>>>>>>>>>>>>>>> loading/unloading modules is a concept known from > >> kernels > >> > >>> etc. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> 3. Simplify the module design by mapping modules > >> purely by > >> > >>>> name > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> LOAD MODULE geo_utils > >> > >>>>>>>>>>>>>>>> LOAD MODULE hive WITH ('version'='2.1') -- no > >> dedicated > >> > >>>>>>>>>>>>>>> 'type='/'module=' > >> > >>>>>>>>>>>>>>>> but allow only 1 module to be loaded parameterized > >> > >>>>>>>>>>>>>>>> UNLOAD hive > >> > >>>>>>>>>>>>>>>> USE MODULES hive, core > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> Please find more details in the reference link. > Looking > >> > >>>> forward > >> > >>>>>> to > >> > >>>>>>>>>>>> your > >> > >>>>>>>>>>>>>>>> feedback. > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> [1] > https://issues.apache.org/jira/browse/FLINK-21045# > >> > >>>>>>>>>>>>>>>> < > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>> > >> > >>>>>> > >> > >>>> > >> > >>> > >> > >> > >> > > >> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-68%3A+Extend+Core+Table+System+with+Pluggable+Modules > >> > >>>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> [2] > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>> > >> > >>>>>> > >> > >>>> > >> > >>> > >> > >> > >> > > >> > https://cwiki.apache.org/confluence/display/FLINK/FLIP-68%3A+Extend+Core+Table+System+with+Pluggable+Modules > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>>> Best, > >> > >>>>>>>>>>>>>>>> Jane > >> > >>>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>>> -- > >> > >>>>>>>>>>>>>> Best regards! > >> > >>>>>>>>>>>>>> Rui Li > >> > >>>>>>>>>>>>>> > >> > >>>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>>> > >> > >>>>>>>>>>> > >> > >>>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>>> > >> > >>>>>>>> > >> > >>>>>>>> > >> > >>>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>> > >> > >>>> > >> > >>>> > >> > >>> > >> > >> > >> > > > >> > > >> > > >> > > > -- Best regards! Rui Li