[
https://issues.apache.org/jira/browse/FLINK-21045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17275216#comment-17275216
]
Jane Chan commented on FLINK-21045:
-----------------------------------
Hi everyone, thanks for the discussion and the opinions, and I'm sorry for the
late reply.
IIUC, we seem to have three core unanswered questions
# Do we need to provide a mechanism for users to change resolution order
conveniently? E.g .`{{USE MODULE}}` syntax is proposed.
# SQL syntax upon `{{CREATE/DROP MODULE}}` v.s. `{{LOAD/UNLOAD MODULE}}`.
# Do we need to keep the module instance's uniqueness, or is it ok to map
modules purely by name? (Btw this question seems to be discussed before, starts
from [here|https://www.mail-archive.com/[email protected]/msg30589.html],
the received comments are "_Jark has a good point. However, I think validation
logic can put in place to restrict one instance per type. Maybe the doc needs
to be specific on this._" and "_So at least, we can have a validation to
restrict one module instance per type in the first version._") However, I
cannot find this validation on the impl side. Currently, the module name is an
alias to the module instance.
E.g.
{code:scala}
@Test
def testLoadModuleInstanceTwice(): Unit = {
val moduleManager = new ModuleManager // this will load CoreModule by
default
val factory = new CoreModuleFactory
moduleManager.loadModule("CORE", factory.createModule(
Map[String, String]("type" -> "core").asJava))
assert(moduleManager.listModules().containsAll(List("core",
"CORE").asJava))
}
{code}
IMO,
# It's not very user-friendly to manually unload/load modules to shift the
order. For the syntax `{{USE MODULE}}`, I think `{{USE}}` sounds like
expressing a mutual-exclusive concept, E.g., `{{USE CATALOG}}`. While Module's
functions don't have namespaces, it's a little bit hard to express a kind of
"sth is specified" meaning. I would like to use `{{RELOAD MODULE}}` to
expressing upgrading the priority of a loaded module.
# I don't have a strong opinion on `{{CREATE/DROP MODULE}}` v.s.
`{{LOAD/UNLOAD MODULE}}`. But once we choose to use `{{CREATE/DROP MODULE}}`,
we'd better keep API consistent with the syntax.
I think it's time to involve more thoughts and suggestions. I'll start a
mailing discussion.
Best, Jane
> Support 'load module' and 'unload module' SQL syntax
> ----------------------------------------------------
>
> Key: FLINK-21045
> URL: https://issues.apache.org/jira/browse/FLINK-21045
> Project: Flink
> Issue Type: Improvement
> Components: Table SQL / Planner
> Affects Versions: 1.13.0
> Reporter: Nicholas Jiang
> Assignee: Jane Chan
> Priority: Major
> Fix For: 1.13.0
>
>
> At present, Flink SQL doesn't support the 'load module' and 'unload module'
> SQL syntax. It's necessary for uses in the situation that users load and
> unload user-defined module through table api or sql client.
> SQL syntax has been proposed in FLIP-68:
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-68%3A+Extend+Core+Table+System+with+Pluggable+Modules
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
