Hi all,

If there is no question related to this FLIP, we will start the voting
thread on 3/6 (Monday).  thank you all.

Best Regards,
Ran Tao
https://github.com/chucheng92


Ran Tao <chucheng...@gmail.com> 于2023年3月1日周三 17:40写道:

> Hi, Timo. thanks.
>
> I have copied the content of docs and updated the FLIP.
>
> Thanks for your advice about consistency(ILIKE).
> Because calcite already support parse ILIKE and exist
> SqlLibraryOperators.ILIKE(which means it's not std).
> It's will not difficult to support it, and we just need to support it in
> table & sql api and not need to change sql keywords or Parser.jj.
>
> However, in flink docs, we may let users know that this is not standard,
> just for better use.
>
> Best Regards,
> Ran Tao
>
>
> Timo Walther <twal...@apache.org> 于2023年2月28日周二 22:23写道:
>
>> Hi Ran Tao,
>>
>> Thanks for working on this FLIP. The FLIP is in a pretty good shape
>> already and I don't have much to add.
>>
>> Will we also support ILIKE in queries? Or is this a pure DDL
>> expressions? For consistency, we should support it in SELECT and Table
>> API as well. I hope this is not too much effort. I hope everybody is
>> aware that ILIKE is not standard compliant but seems to be used by a
>> variety of vendors.
>>
>>  > Because it may be modified under discuss, we put it on the google
>> docs. please see FLIP-297: Improve Auxiliary Sql Statements Docs
>>
>> This comment confused me. It would be nice to have the Wiki page as the
>> single source of truth and abandon the Google doc. In the past we used
>> Google Docs more but nowadays I support using only the Wiki to avoid any
>> confusion.
>>
>> Regards,
>> Timo
>>
>>
>> On 28.02.23 12:51, Ran Tao wrote:
>> > thanks Sergey, sounds good.
>> > You can add in FLIP ticket[1].
>> >
>> > [1] https://issues.apache.org/jira/browse/FLINK-31256
>> >
>> > Best Regards,
>> > Ran Tao
>> > https://github.com/chucheng92
>> >
>> >
>> > Sergey Nuyanzin <snuyan...@gmail.com> 于2023年2月28日周二 19:44写道:
>> >
>> >>>> Currently I think we can load from the jar and check the services
>> file to
>> >>>> get the connector type. but is it necessary we may continue to
>> discuss.
>> >>>> Hi, Sergey, WDYT?
>> >>
>> >> Another idea is FactoryUtil#discoverFactories and
>> >> check if it implements DynamicTableSourceFactory or
>> DynamicTableSinkFactory
>> >> with versions it could be trickier...
>> >> Moreover it seems the version could be a part of the name sometimes[1].
>> >> I think name and type could be enough or please correct me if I'm wrong
>> >>
>> >>>> or can we open a single ticket under this FLIP?
>> >> I have a relatively old jira issue[2] for showing connectors with a
>> poc pr.
>> >> Could I propose to move this jira issue as a subtask under the FLIP
>> one and
>> >> revive it?
>> >>
>> >> [1]
>> >>
>> >>
>> https://github.com/apache/flink/blob/161014149e803bfd1d3653badb230b2ed36ce3cb/flink-table/flink-table-common/src/main/java/org/apache/flink/table/factories/Factory.java#L65-L69
>> >> [2] https://issues.apache.org/jira/browse/FLINK-25788
>> >>
>> >> On Tue, Feb 28, 2023 at 11:56 AM Ran Tao <chucheng...@gmail.com>
>> wrote:
>> >>
>> >>> Hi, Jark. thanks.
>> >>>> About ILIKE
>> >>> I have updated the FLIP for ILIKE support (Including existing
>> showTables
>> >> &
>> >>> showColumns how to change).
>> >>>
>> >>>> About show connectors @Sergey,
>> >>> Currently I think we can load from the jar and check the services
>> file to
>> >>> get the connector type. but is it necessary we may continue to
>> discuss.
>> >>> Hi, Sergey, WDYT?or can we open a single ticket under this FLIP?
>> >>>
>> >>>
>> >>> Best Regards,
>> >>> Ran Tao
>> >>>
>> >>>
>> >>> Jark Wu <imj...@gmail.com> 于2023年2月28日周二 17:45写道:
>> >>>
>> >>>> Besides, if we introduce the ILIKE, we should also add this feature
>> for
>> >>>> the previous SHOW with LIKE statements. They should be included in
>> this
>> >>>> FLIP.
>> >>>>
>> >>>> Best,
>> >>>> Jark
>> >>>>
>> >>>>> 2023年2月28日 17:40,Jark Wu <imj...@gmail.com> 写道:
>> >>>>>
>> >>>>> Hi Ran,
>> >>>>>
>> >>>>> Could you add descriptions about what’s the behavior and differences
>> >>>> between the LIKE and ILIKE?
>> >>>>>
>> >>>>> Besides, I don’t see the SHOW CONNECTOR syntax and description and
>> >> how
>> >>>> it works in the FLIP. Is it intended to be included in this FLIP?
>> >>>>>
>> >>>>> Best,
>> >>>>> Jark
>> >>>>>
>> >>>>>
>> >>>>>> 2023年2月28日 10:58,Ran Tao <chucheng...@gmail.com> 写道:
>> >>>>>>
>> >>>>>> Hi, guys. thanks for advices.
>> >>>>>>
>> >>>>>> allow me to make a small summary:
>> >>>>>>
>> >>>>>> 1.Support ILIKE
>> >>>>>> 2.Using catalog api to support show operations
>> >>>>>> 3.Need a dedicated FLIP try to support INFORMATION_SCHEMA
>> >>>>>> 4.Support SHOW CONNECTORS
>> >>>>>>
>> >>>>>> If there are no other questions, i will try to start a VOTE for
>> this
>> >>>> FLIP.
>> >>>>>> WDYT?
>> >>>>>>
>> >>>>>> Best Regards,
>> >>>>>> Ran Tao
>> >>>>>>
>> >>>>>>
>> >>>>>> Sergey Nuyanzin <snuyan...@gmail.com> 于2023年2月27日周一 21:12写道:
>> >>>>>>
>> >>>>>>> Hi Jark,
>> >>>>>>>
>> >>>>>>> thanks for your comment.
>> >>>>>>>
>> >>>>>>>> Considering they
>> >>>>>>>> are orthogonal and information schema requires more complex
>> design
>> >>> and
>> >>>>>>>> discussion, it deserves a separate FLIP
>> >>>>>>> I'm ok with a separate FLIP for INFORMATION_SCHEMA.
>> >>>>>>>
>> >>>>>>>> Sergey, are you willing to contribute this FLIP?
>> >>>>>>> Seems I need to have more research done for that.
>> >>>>>>> I would try to help/contribute here
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> On Mon, Feb 27, 2023 at 3:46 AM Ran Tao <chucheng...@gmail.com>
>> >>> wrote:
>> >>>>>>>
>> >>>>>>>> HI, Jing. thanks.
>> >>>>>>>>
>> >>>>>>>> @about ILIKE, from my collections of some popular engines founds
>> >>> that
>> >>>>>>> just
>> >>>>>>>> snowflake has this syntax in show with filtering.
>> >>>>>>>> do we need to support it? if yes, then current some existed show
>> >>>>>>> operations
>> >>>>>>>> need to be addressed either.
>> >>>>>>>> @about ShowOperation with like. it's a good idea. yes, two
>> >>> parameters
>> >>>> for
>> >>>>>>>> constructor can work. thanks for your advice.
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Best Regards,
>> >>>>>>>> Ran Tao
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>> Jing Ge <j...@ververica.com.invalid> 于2023年2月27日周一 06:29写道:
>> >>>>>>>>
>> >>>>>>>>> Hi,
>> >>>>>>>>>
>> >>>>>>>>> @Aitozi
>> >>>>>>>>>
>> >>>>>>>>> This is exactly why LoD has been introduced: to avoid exposing
>> >>>> internal
>> >>>>>>>>> structure(2nd and lower level API).
>> >>>>>>>>>
>> >>>>>>>>> @Jark
>> >>>>>>>>>
>> >>>>>>>>> IMHO, there is no conflict between LoD and "High power-to-weight
>> >>>> ratio"
>> >>>>>>>>> with the given example, List.subList() returns List interface
>> >>> itself,
>> >>>>>>> no
>> >>>>>>>>> internal or further interface has been exposed. After offering
>> >>>>>>>>> tEvn.getCatalog(), "all" methods in Catalog Interface have been
>> >>>>>>> provided
>> >>>>>>>> by
>> >>>>>>>>> TableEnvironment(via getCatalog()). From user's perspective and
>> >>>>>>>> maintenance
>> >>>>>>>>> perspective there is no/less difference between providing them
>> >>>> directly
>> >>>>>>>> via
>> >>>>>>>>> TableEnvironment or via getCatalog(). They are all exposed.
>> Using
>> >>>>>>>>> getCatalog() will reduce the number of boring wrapper methods,
>> >> but
>> >>> on
>> >>>>>>> the
>> >>>>>>>>> other hand not every method in Catalog needs to be exposed, so
>> >> the
>> >>>>>>> number
>> >>>>>>>>> of wrapper methods would be limited/less, if we didn't expose
>> >>>> Catalog.
>> >>>>>>>>> Nevertheless, since we already offered getCatalog(), it makes
>> >> sense
>> >>>> to
>> >>>>>>>>> continue using it. The downside is the learning effort for users
>> >> -
>> >>>> they
>> >>>>>>>>> have to know that listDatabases() is hidden in Catalog, go to
>> >>> another
>> >>>>>>>>> haystack and then find the needle in there.
>> >>>>>>>>>
>> >>>>>>>>> +1 for Information schema with a different FLIP. From a design
>> >>>>>>>> perspective,
>> >>>>>>>>> information schema should be the first choice for most cases and
>> >>> easy
>> >>>>>>> to
>> >>>>>>>>> use. Catalog, on the other hand, will be more powerful and offer
>> >>> more
>> >>>>>>>>> advanced features.
>> >>>>>>>>>
>> >>>>>>>>> Best regards,
>> >>>>>>>>> Jing
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> On Sat, Feb 25, 2023 at 3:57 PM Jark Wu <imj...@gmail.com>
>> >> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> Hi Sergey,
>> >>>>>>>>>>
>> >>>>>>>>>> I think INFORMATION_SCHEMA is a very interesting idea, and I
>> >> hope
>> >>> we
>> >>>>>>>> can
>> >>>>>>>>>> support it. However, it doesn't conflict with the idea of
>> >>> auxiliary
>> >>>>>>>>>> statements. I can see different benefits of them. The
>> >> information
>> >>>>>>>> schema
>> >>>>>>>>>> provides powerful and flexible capabilities but needs to learn
>> >> the
>> >>>>>>>>> complex
>> >>>>>>>>>> entity relationship[1]. The auxiliary SQL statements are super
>> >>> handy
>> >>>>>>>> and
>> >>>>>>>>>> can resolve most problems, but they offer limited features.
>> >>>>>>>>>>
>> >>>>>>>>>> I can see almost all the mature systems support both of them. I
>> >>>> think
>> >>>>>>>> it
>> >>>>>>>>>> also makes sense to support both of them in Flink. Considering
>> >>> they
>> >>>>>>>>>> are orthogonal and information schema requires more complex
>> >> design
>> >>>>>>> and
>> >>>>>>>>>> discussion, it deserves a separate FLIP. Sergey, are you
>> willing
>> >>> to
>> >>>>>>>>>> contribute this FLIP?
>> >>>>>>>>>>
>> >>>>>>>>>> Best,
>> >>>>>>>>>> Jark
>> >>>>>>>>>>
>> >>>>>>>>>> [1]:
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>
>> >>>
>> >>
>> https://docs.databricks.com/sql/language-manual/sql-ref-information-schema.html
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> On Fri, 24 Feb 2023 at 22:43, Ran Tao <chucheng...@gmail.com>
>> >>>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>>> Thanks John.
>> >>>>>>>>>>>
>> >>>>>>>>>>> It seems that most people prefer the information_schema
>> >>>>>>>> implementation.
>> >>>>>>>>>>> information_schema does have more benefits (however, the show
>> >>>>>>>> operation
>> >>>>>>>>>> is
>> >>>>>>>>>>> also an option and supplement).
>> >>>>>>>>>>> Otherwise, the sql syntax and keywords may be changed
>> >> frequently.
>> >>>>>>>>>>> Of course, it will be more complicated than the extension of
>> >> the
>> >>>>>>> show
>> >>>>>>>>>>> operation.
>> >>>>>>>>>>> It is necessary to design various tables in
>> information_schema,
>> >>>>>>>> which
>> >>>>>>>>>> may
>> >>>>>>>>>>> take a period of effort.
>> >>>>>>>>>>>
>> >>>>>>>>>>> I will try to design the information_schema and integrate it
>> >> with
>> >>>>>>>>> flink.
>> >>>>>>>>>>> This may be a relatively big feature for me. I hope you guys
>> >> can
>> >>>>>>> give
>> >>>>>>>>>>> comments and opinions later.
>> >>>>>>>>>>> Thank you all.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Best Regards,
>> >>>>>>>>>>> Ran Tao
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> John Roesler <vvcep...@apache.org> 于2023年2月24日周五 21:53写道:
>> >>>>>>>>>>>
>> >>>>>>>>>>>> Hello Ran,
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Thanks for the FLIP!
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Do you mind if we revisit the topic of doing this by adding
>> an
>> >>>>>>>>>>> Information
>> >>>>>>>>>>>> schema? The SHOW approach requires modifying the
>> >> parser/language
>> >>>>>>>> for
>> >>>>>>>>>>> every
>> >>>>>>>>>>>> gap we identify. On the flip side, an Information schema is
>> >> much
>> >>>>>>>>> easier
>> >>>>>>>>>>> to
>> >>>>>>>>>>>> discover and remember how to use, and the ability to run
>> >> queries
>> >>>>>>> on
>> >>>>>>>>> it
>> >>>>>>>>>> is
>> >>>>>>>>>>>> quite valuable for admins. It’s also better for Flink
>> >>>>>>> maintainers,
>> >>>>>>>>>>> because
>> >>>>>>>>>>>> the information tables’ schemas can be evolved over time just
>> >>>>>>> like
>> >>>>>>>>>>> regular
>> >>>>>>>>>>>> tables, whereas every change to a SHOW statement would be a
>> >>>>>>>> breaking
>> >>>>>>>>>>>> change.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> I understand that it may seem like a big effort, but we’re
>> >>>>>>>> proposing
>> >>>>>>>>>>> quite
>> >>>>>>>>>>>> a big extension to the space of SHOW statement, so it seems
>> >>>>>>>>> appropriate
>> >>>>>>>>>>> to
>> >>>>>>>>>>>> take the opportunity and migrate to a better framework rather
>> >>>>>>> than
>> >>>>>>>>>>>> incrementally building on (and tying us even more firmly to)
>> >> the
>> >>>>>>>>>> existing
>> >>>>>>>>>>>> approach.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Thanks for your consideration,
>> >>>>>>>>>>>> John
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> On Fri, Feb 24, 2023, at 05:58, Sergey Nuyanzin wrote:
>> >>>>>>>>>>>>> thanks for explanation
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> But it's not clear to me what exactly
>> >>>>>>>>>>>>>> you want to display? Is it the name of the plugin?
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> I was thinking about name, type (source/sink) and may be
>> >>>>>>> version
>> >>>>>>>>> (not
>> >>>>>>>>>>>> sure
>> >>>>>>>>>>>>> if it's possible right now)
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> On Fri, Feb 24, 2023 at 12:46 PM Ran Tao <
>> >>>>>>> chucheng...@gmail.com>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Hi, Sergey. thanks. first step we can support filtering for
>> >>>>>>> show
>> >>>>>>>>>>>> operations
>> >>>>>>>>>>>>>> in this FLIP try to align other engines.
>> >>>>>>>>>>>>>> If we want to support describe other objects, of course we
>> >>>>>>> need
>> >>>>>>>> to
>> >>>>>>>>>>>> design
>> >>>>>>>>>>>>>> how to get these metadatas or informations and
>> printAsStyle.
>> >>>>>>> (So
>> >>>>>>>>> it
>> >>>>>>>>>>>> maybe
>> >>>>>>>>>>>>>> need another FLIP for more details).
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Does it make sense to add support for connectors e.g. show
>> >>>>>>>>>>>>>>> {sink|source|all} connectors?
>> >>>>>>>>>>>>>> I think we can support it, currently flink do support some
>> >>>>>>>>>> operations
>> >>>>>>>>>>>> only
>> >>>>>>>>>>>>>> for flink itself such as showJobs. But it's not clear to me
>> >>>>>>> what
>> >>>>>>>>>>> exactly
>> >>>>>>>>>>>>>> you want to display? Is it the name of the plugin?
>> >>>>>>>>>>>>>> Just Like:
>> >>>>>>>>>>>>>> Kafka
>> >>>>>>>>>>>>>> Hudi
>> >>>>>>>>>>>>>> Files
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Best Regards,
>> >>>>>>>>>>>>>> Ran Tao
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Sergey Nuyanzin <snuyan...@gmail.com> 于2023年2月24日周五
>> >> 19:11写道:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Thanks for driving the FLIP
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I have a couple of questions
>> >>>>>>>>>>>>>>> Am I right that INFORMATION_SCHEMA mentioned by Timo[1]
>> is
>> >>>>>>>> out
>> >>>>>>>>> of
>> >>>>>>>>>>>> scope
>> >>>>>>>>>>>>>> of
>> >>>>>>>>>>>>>>> this FLIP?
>> >>>>>>>>>>>>>>> I noticed there are some support of it in
>> >>>>>>>>>>>> Spark[2]/Hive[3]/Snowflake[4]
>> >>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>> others
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Does it make sense to add support for connectors e.g. show
>> >>>>>>>>>>>>>>> {sink|source|all} connectors?
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> [1]
>> >>>>>>>>>>>
>> >> https://lists.apache.org/thread/2g108qlfwbhb56wnoc5qj0yq29dvq1vv
>> >>>>>>>>>>>>>>> [2] https://issues.apache.org/jira/browse/SPARK-16452
>> >>>>>>>>>>>>>>> [3] https://issues.apache.org/jira/browse/HIVE-1010
>> >>>>>>>>>>>>>>> [4]
>> >> https://docs.snowflake.com/en/sql-reference/info-schema
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> On Fri, Feb 24, 2023 at 4:19 AM Jark Wu <imj...@gmail.com
>> >
>> >>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Hi Jing,
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> we'd better reduce the dependency chain and follow the
>> >>>>>>> Law
>> >>>>>>>>> of
>> >>>>>>>>>>>>>>>> Demeter(LoD, clean code).
>> >>>>>>>>>>>>>>>>> Adding a new method in TableEnvironment is therefore
>> >>>>>>>> better
>> >>>>>>>>>> than
>> >>>>>>>>>>>>>>> calling
>> >>>>>>>>>>>>>>>> an API chain
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> I think I don't fully agree that LoD is a good practice.
>> >>>>>>>>>>> Actually, I
>> >>>>>>>>>>>>>>> would
>> >>>>>>>>>>>>>>>> prefer to keep the API clean and concise.
>> >>>>>>>>>>>>>>>> This is also the Java Collection Framework design
>> >>>>>>> principle
>> >>>>>>>>> [1]:
>> >>>>>>>>>>>> "High
>> >>>>>>>>>>>>>>>> power-to-weight ratio". Otherwise,
>> >>>>>>>>>>>>>>>> it will explode the API interfaces with different
>> >>>>>>>> combinations
>> >>>>>>>>>> of
>> >>>>>>>>>>>>>>> methods.
>> >>>>>>>>>>>>>>>> Currently, TableEnvironment
>> >>>>>>>>>>>>>>>> already provides 60+ methods.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> IMO, with the increasing methods of accessing and
>> >>>>>>>> manipulating
>> >>>>>>>>>>>>>> metadata,
>> >>>>>>>>>>>>>>>> they can be extracted to
>> >>>>>>>>>>>>>>>> a separate interface, where we can add richer methods.
>> >>>>>>> This
>> >>>>>>>>> work
>> >>>>>>>>>>>> can be
>> >>>>>>>>>>>>>>>> aligned with the
>> >>>>>>>>>>>>>>>> CatalogManager interface (FLIP-295) [2].
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Best,
>> >>>>>>>>>>>>>>>> Jark
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> [1]:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>
>> >>>
>> >>
>> https://stackoverflow.com/questions/7568819/why-no-tail-or-head-method-in-list-to-get-last-or-first-element
>> >>>>>>>>>>>>>>>> [2]:
>> >>>>>>>>>>>>
>> >>> https://lists.apache.org/thread/9bnjblgd9wvrl75lkm84oo654c4lqv70
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Fri, 24 Feb 2023 at 10:38, Aitozi <
>> >>>>>>> gjying1...@gmail.com>
>> >>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>>>    Thanks for the nice proposal, Ran.
>> >>>>>>>>>>>>>>>>>    Regarding this api usage, I have some discussion
>> >>>>>>> with
>> >>>>>>>>>>> @twalthr
>> >>>>>>>>>>>>>>> before
>> >>>>>>>>>>>>>>>>> as here <
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>
>> https://github.com/apache/flink/pull/15137#issuecomment-1356124138
>> >>>>>>>>>
>> >>>>>>>>>>>>>>>>> Personally, I think leaking the Catalog to the user side
>> >>>>>>>> is
>> >>>>>>>>>> not
>> >>>>>>>>>>>>>>> suitable,
>> >>>>>>>>>>>>>>>>> since there are some read/write operations in the
>> >>>>>>> Catalog,
>> >>>>>>>>> the
>> >>>>>>>>>>>>>>>>> TableEnvironment#getCatalog will expose all of them to
>> >>>>>>> the
>> >>>>>>>>>> user
>> >>>>>>>>>>>> side.
>> >>>>>>>>>>>>>>> So
>> >>>>>>>>>>>>>>>> I
>> >>>>>>>>>>>>>>>>> learned to add a new api in TableEnvironment to reduce
>> >>>>>>>>>> reliance
>> >>>>>>>>>>> on
>> >>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> current TableEnvironment#getCatalog.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Thanks,
>> >>>>>>>>>>>>>>>>> Aitozi
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Ran Tao <chucheng...@gmail.com> 于2023年2月23日周四 23:44写道:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Hi, JingSong, Jing.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> thank for sharing your opinions.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> What you say makes sense, both approaches have pros
>> >>>>>>> and
>> >>>>>>>>>> cons.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> If it is a modification of `TableEnvrionment`, such as
>> >>>>>>>>>>>>>>>>>> listDatabases(catalog). It is actually consistent with
>> >>>>>>>> the
>> >>>>>>>>>>> other
>> >>>>>>>>>>>>>>>>> overloaded
>> >>>>>>>>>>>>>>>>>> methods before,
>> >>>>>>>>>>>>>>>>>> and defining this method means that TableEnvrionment
>> >>>>>>>> does
>> >>>>>>>>>>>> provide
>> >>>>>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>>>> capability (rather than relying on the functionality
>> >>>>>>> of
>> >>>>>>>>>>> another
>> >>>>>>>>>>>>>>> class).
>> >>>>>>>>>>>>>>>>>> The disadvantage is that api changes may be required,
>> >>>>>>>> and
>> >>>>>>>>>> may
>> >>>>>>>>>>>>>>> continue
>> >>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>> be modified in the future.
>> >>>>>>>>>>>>>>>>>> But from the TableEnvrionment itself, it really
>> >>>>>>> doesn't
>> >>>>>>>>> pay
>> >>>>>>>>>>>>>> attention
>> >>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>> how the underlying layer is implemented.
>> >>>>>>>>>>>>>>>>>> (Although it is actually taken from the catalogManager
>> >>>>>>>> at
>> >>>>>>>>>>>> present,
>> >>>>>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>> another question)
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Judging from the current dependencies,
>> >>>>>>>>> flink-table-api-java
>> >>>>>>>>>>>>>> strongly
>> >>>>>>>>>>>>>>>>> relies
>> >>>>>>>>>>>>>>>>>> on flink-table-common to use various common classes
>> >>>>>>> and
>> >>>>>>>>>>>> interfaces,
>> >>>>>>>>>>>>>>>>>> especially the catalog interface.
>> >>>>>>>>>>>>>>>>>> So we can extract various metadata information in the
>> >>>>>>>>>> catalog
>> >>>>>>>>>>>>>> through
>> >>>>>>>>>>>>>>>>>> `tEnv.getCatalog`.
>> >>>>>>>>>>>>>>>>>> The advantage is that it will not cause api
>> >>>>>>>> modification,
>> >>>>>>>>>> but
>> >>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>> method
>> >>>>>>>>>>>>>>>>>> of use breaks LoD.
>> >>>>>>>>>>>>>>>>>> In fact, the current flink-table-api-java design is
>> >>>>>>>>>> completely
>> >>>>>>>>>>>>>> bound
>> >>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>> catalog interface.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> If the mandatory modification of PublicApi is
>> >>>>>>>> constrained
>> >>>>>>>>>> (may
>> >>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>>> modified
>> >>>>>>>>>>>>>>>>>> again and later), I tend to use `tEnv.getCatalog`
>> >>>>>>>>> directly,
>> >>>>>>>>>>>>>> otherwise
>> >>>>>>>>>>>>>>>>>> It would actually be more standard to add overloaded
>> >>>>>>>>> methods
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>> `TableEnvrionment`.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Another question, can the later capabilities of
>> >>>>>>>>>>>> TableEnvrionment be
>> >>>>>>>>>>>>>>>>>> implemented through SupportXXX?
>> >>>>>>>>>>>>>>>>>> In order to solve the problem that the method needs to
>> >>>>>>>> be
>> >>>>>>>>>>> added
>> >>>>>>>>>>>> in
>> >>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>> future. This kind of usage occurs frequently in flink.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Looking forward to your other considerations,
>> >>>>>>>>>>>>>>>>>> and also try to wait to see if there are other
>> >>>>>>> relevant
>> >>>>>>>>> API
>> >>>>>>>>>>>>>> designers
>> >>>>>>>>>>>>>>>> or
>> >>>>>>>>>>>>>>>>>> committers to provide comments.
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Best Regards,
>> >>>>>>>>>>>>>>>>>> Ran Tao
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> Jing Ge <j...@ververica.com.invalid> 于2023年2月23日周四
>> >>>>>>>>> 18:58写道:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Hi Jingson,
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Thanks for sharing your thoughts. Please see my
>> >>>>>>> reply
>> >>>>>>>>>> below.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 10:16 AM Jingsong Li <
>> >>>>>>>>>>>>>>> jingsongl...@gmail.com
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Hi Jing Ge,
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> First, flink-table-common contains all common
>> >>>>>>>> classes
>> >>>>>>>>> of
>> >>>>>>>>>>>> Flink
>> >>>>>>>>>>>>>>>> Table,
>> >>>>>>>>>>>>>>>>>>>> I think it is hard to bypass its dependence.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> If any time when we use flink-table-api-java, we
>> >>>>>>> have
>> >>>>>>>> to
>> >>>>>>>>>>> cross
>> >>>>>>>>>>>>>>>> through
>> >>>>>>>>>>>>>>>>>>> flink-table-api-java and use flink-table-common, we
>> >>>>>>>>> should
>> >>>>>>>>>>>>>>> reconsider
>> >>>>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>>>> design of these two modules and how
>> >>>>>>> interfaces/classes
>> >>>>>>>>> are
>> >>>>>>>>>>>>>>> classified
>> >>>>>>>>>>>>>>>>>> into
>> >>>>>>>>>>>>>>>>>>> those modules.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Secondly, almost all methods in Catalog looks
>> >>>>>>> useful
>> >>>>>>>>> to
>> >>>>>>>>>>> me,
>> >>>>>>>>>>>> so
>> >>>>>>>>>>>>>> if
>> >>>>>>>>>>>>>>>> we
>> >>>>>>>>>>>>>>>>>>>> are following LoD, we should add all methods again
>> >>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>> TableEnvironment. I think it is redundant.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> That is the enlarged issue I mentioned previously. A
>> >>>>>>>>>> simple
>> >>>>>>>>>>>>>>> solution
>> >>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>> move Catalog to the top level API. The fact is that
>> >>>>>>> a
>> >>>>>>>>>>> catalog
>> >>>>>>>>>>>>>>> package
>> >>>>>>>>>>>>>>>>>>> already exists in flink-table-api-java but the
>> >>>>>>> Catalog
>> >>>>>>>>>>>> interface
>> >>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>>>>>> flink-table-common. I don't know the historical
>> >>>>>>>> context
>> >>>>>>>>> of
>> >>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>> design.
>> >>>>>>>>>>>>>>>>>>> Maybe you could share some insight with us? Thanks
>> >>>>>>> in
>> >>>>>>>>>>> advance.
>> >>>>>>>>>>>>>>> Beyond
>> >>>>>>>>>>>>>>>>>> that,
>> >>>>>>>>>>>>>>>>>>> there should be other AOP options but need more time
>> >>>>>>>> to
>> >>>>>>>>>>>> figure it
>> >>>>>>>>>>>>>>>> out.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> And, this API chain does not look deep.
>> >>>>>>>>>>>>>>>>>>>> -
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>
>> "tEnv.getCatalog(tEnv.getCurrentCatalog()).get().listDatabases()"
>> >>>>>>>>>>>>>>>>>>>> looks a little complicated. The complex part is
>> >>>>>>>> ahead.
>> >>>>>>>>>>>>>>>>>>>> - If we have a method to get Catalog directly, can
>> >>>>>>>> be
>> >>>>>>>>>>>> simplify
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>> "tEnv.catalog().listDatabase()", this is simple.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> Commonly, it will need more effort to always follow
>> >>>>>>>> LoD,
>> >>>>>>>>>> but
>> >>>>>>>>>>>> for
>> >>>>>>>>>>>>>>> the
>> >>>>>>>>>>>>>>>>> top
>> >>>>>>>>>>>>>>>>>>> level facade API like TableEnvironment, both the API
>> >>>>>>>>>>>> developer,
>> >>>>>>>>>>>>>> API
>> >>>>>>>>>>>>>>>>>>> consumer and the project itself from a long-term
>> >>>>>>>>>> perspective
>> >>>>>>>>>>>> will
>> >>>>>>>>>>>>>>>>> benefit
>> >>>>>>>>>>>>>>>>>>> from sticking to LoD. Since we already have the
>> >>>>>>>>>>>> getCatalog(String
>> >>>>>>>>>>>>>>>>>> catalog)
>> >>>>>>>>>>>>>>>>>>> method in TableEnvironment, it also makes sense to
>> >>>>>>>>> follow
>> >>>>>>>>>>> your
>> >>>>>>>>>>>>>>>>>> suggestion,
>> >>>>>>>>>>>>>>>>>>> if we only want to limit/avoid public API changes.
>> >>>>>>> But
>> >>>>>>>>>>> please
>> >>>>>>>>>>>> be
>> >>>>>>>>>>>>>>>> aware
>> >>>>>>>>>>>>>>>>>> that
>> >>>>>>>>>>>>>>>>>>> we will have all known long-term drawbacks because
>> >>>>>>> of
>> >>>>>>>>> LoD
>> >>>>>>>>>>>>>>>>>>> violation, especially the cross modules violation. I
>> >>>>>>>>> just
>> >>>>>>>>>>>> checked
>> >>>>>>>>>>>>>>> all
>> >>>>>>>>>>>>>>>>>>> usages of getCatalog(String catalog) in the master
>> >>>>>>>>> branch.
>> >>>>>>>>>>>>>>> Currently
>> >>>>>>>>>>>>>>>>>> there
>> >>>>>>>>>>>>>>>>>>> are very limited calls. It is better to pay
>> >>>>>>> attention
>> >>>>>>>> to
>> >>>>>>>>>> it
>> >>>>>>>>>>>>>> before
>> >>>>>>>>>>>>>>> it
>> >>>>>>>>>>>>>>>>>> goes
>> >>>>>>>>>>>>>>>>>>> worse. Just my 2 cents. :)
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Best,
>> >>>>>>>>>>>>>>>>>>>> Jingsong
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 4:47 PM Jing Ge
>> >>>>>>>>>>>>>>> <j...@ververica.com.invalid
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Hi Jingson,
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Thanks for the knowledge sharing. IMHO, it looks
>> >>>>>>>>> more
>> >>>>>>>>>>>> like a
>> >>>>>>>>>>>>>>>> design
>> >>>>>>>>>>>>>>>>>>>>> guideline question than just avoiding public API
>> >>>>>>>>>> change.
>> >>>>>>>>>>>>>> Please
>> >>>>>>>>>>>>>>>>>> correct
>> >>>>>>>>>>>>>>>>>>>> me
>> >>>>>>>>>>>>>>>>>>>>> if I'm wrong.
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Catalog is in flink-table-common module and
>> >>>>>>>>>>>> TableEnvironment
>> >>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>>>>>>>> flink-table-api-java. Depending on how and where
>> >>>>>>>>> those
>> >>>>>>>>>>>>>> features
>> >>>>>>>>>>>>>>>>>>> proposed
>> >>>>>>>>>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>>>>>>>> this FLIP will be used, we'd better reduce the
>> >>>>>>>>>>> dependency
>> >>>>>>>>>>>>>> chain
>> >>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>> follow
>> >>>>>>>>>>>>>>>>>>>>> the Law of Demeter(LoD, clean code) [1]. Adding
>> >>>>>>> a
>> >>>>>>>>> new
>> >>>>>>>>>>>> method
>> >>>>>>>>>>>>>> in
>> >>>>>>>>>>>>>>>>>>>>> TableEnvironment is therefore better than
>> >>>>>>> calling
>> >>>>>>>> an
>> >>>>>>>>>> API
>> >>>>>>>>>>>>>> chain.
>> >>>>>>>>>>>>>>>> It
>> >>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>> also
>> >>>>>>>>>>>>>>>>>>>>> more user friendly for the caller, because there
>> >>>>>>>> is
>> >>>>>>>>> no
>> >>>>>>>>>>>> need
>> >>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>> understand
>> >>>>>>>>>>>>>>>>>>>>> the internal structure of the called API. The
>> >>>>>>>>> downside
>> >>>>>>>>>>> of
>> >>>>>>>>>>>>>> doing
>> >>>>>>>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>> that we might have another issue with the
>> >>>>>>> current
>> >>>>>>>>>>>>>>>> TableEnvironment
>> >>>>>>>>>>>>>>>>>>>> design -
>> >>>>>>>>>>>>>>>>>>>>> the TableEnvironment interface got enlarged with
>> >>>>>>>>> more
>> >>>>>>>>>>>> wrapper
>> >>>>>>>>>>>>>>>>>> methods.
>> >>>>>>>>>>>>>>>>>>>> This
>> >>>>>>>>>>>>>>>>>>>>> is a different issue that could be solved with
>> >>>>>>>>>> improved
>> >>>>>>>>>>>>>>>> abstraction
>> >>>>>>>>>>>>>>>>>>>> design
>> >>>>>>>>>>>>>>>>>>>>> in the future. After considering pros and cons,
>> >>>>>>> if
>> >>>>>>>>> we
>> >>>>>>>>>>>> want to
>> >>>>>>>>>>>>>>> add
>> >>>>>>>>>>>>>>>>>> those
>> >>>>>>>>>>>>>>>>>>>>> features now, I would prefer following LoD than
>> >>>>>>>> API
>> >>>>>>>>>>> chain
>> >>>>>>>>>>>>>>> calls.
>> >>>>>>>>>>>>>>>>>> WDYT?
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Best regards,
>> >>>>>>>>>>>>>>>>>>>>> Jing
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> [1]
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>
>> >>>
>> >>
>> https://hackernoon.com/object-oriented-tricks-2-law-of-demeter-4ecc9becad85
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 6:26 AM Ran Tao <
>> >>>>>>>>>>>>>> chucheng...@gmail.com
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Hi Jingsong. thanks. i got it.
>> >>>>>>>>>>>>>>>>>>>>>> In this way, there is no need to introduce new
>> >>>>>>>> API
>> >>>>>>>>>>>> changes.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Best Regards,
>> >>>>>>>>>>>>>>>>>>>>>> Ran Tao
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> Jingsong Li <jingsongl...@gmail.com>
>> >>>>>>>>> 于2023年2月23日周四
>> >>>>>>>>>>>>>> 12:26写道:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Hi Ran,
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> I mean we can just use
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>
>> >> TableEnvironment.getCatalog(getCurrentCatalog).get().listDatabases().
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> We don't need to provide new apis just for
>> >>>>>>>>> utils.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Best,
>> >>>>>>>>>>>>>>>>>>>>>>> Jingsong
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 12:11 PM Ran Tao <
>> >>>>>>>>>>>>>>>>> chucheng...@gmail.com>
>> >>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Hi Jingsong, thanks.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> The implementation of these statements in
>> >>>>>>>>>>>>>>>>> TableEnvironmentImpl
>> >>>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>> called
>> >>>>>>>>>>>>>>>>>>>>>>>> through the catalog api.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> but it does support some new override
>> >>>>>>>> methods
>> >>>>>>>>> on
>> >>>>>>>>>>> the
>> >>>>>>>>>>>>>>>> catalog
>> >>>>>>>>>>>>>>>>>> api
>> >>>>>>>>>>>>>>>>>>>> side,
>> >>>>>>>>>>>>>>>>>>>>>>> and
>> >>>>>>>>>>>>>>>>>>>>>>>> I will update it later. Thank you.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> e.g.
>> >>>>>>>>>>>>>>>>>>>>>>>> TableEnvironmentImpl
>> >>>>>>>>>>>>>>>>>>>>>>>>    @Override
>> >>>>>>>>>>>>>>>>>>>>>>>>    public String[] listDatabases() {
>> >>>>>>>>>>>>>>>>>>>>>>>>        return catalogManager
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> .getCatalog(catalogManager.getCurrentCatalog())
>> >>>>>>>>>>>>>>>>>>>>>>>>                .get()
>> >>>>>>>>>>>>>>>>>>>>>>>>                .listDatabases()
>> >>>>>>>>>>>>>>>>>>>>>>>>                .toArray(new String[0]);
>> >>>>>>>>>>>>>>>>>>>>>>>>    }
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>> >>>>>>>>>>>>>>>>>>>>>>>> Ran Tao
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Jingsong Li <jingsongl...@gmail.com>
>> >>>>>>>>>>> 于2023年2月23日周四
>> >>>>>>>>>>>>>>>> 11:47写道:
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks for the proposal.
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> +1 for the proposal.
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> I am confused about "Proposed
>> >>>>>>>>> TableEnvironment
>> >>>>>>>>>>> SQL
>> >>>>>>>>>>>>>> API
>> >>>>>>>>>>>>>>>>>>> Changes",
>> >>>>>>>>>>>>>>>>>>>> can
>> >>>>>>>>>>>>>>>>>>>>>>>>> we just use catalog api for this
>> >>>>>>>>> requirement?
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Best,
>> >>>>>>>>>>>>>>>>>>>>>>>>> Jingsong
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Feb 23, 2023 at 10:48 AM Jacky
>> >>>>>>>> Lau <
>> >>>>>>>>>>>>>>>>>>> liuyong...@gmail.com
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ran:
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for driving the FLIP. the
>> >>>>>>> google
>> >>>>>>>>> doc
>> >>>>>>>>>>>> looks
>> >>>>>>>>>>>>>>>> really
>> >>>>>>>>>>>>>>>>>>> good.
>> >>>>>>>>>>>>>>>>>>>> it
>> >>>>>>>>>>>>>>>>>>>>>> is
>> >>>>>>>>>>>>>>>>>>>>>>>>>> important to improve user interactive
>> >>>>>>>>>>>> experience.
>> >>>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>> support
>> >>>>>>>>>>>>>>>>>>>>>> this
>> >>>>>>>>>>>>>>>>>>>>>>>>>> feature.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Jing Ge <j...@ververica.com.invalid>
>> >>>>>>>>>>>> 于2023年2月23日周四
>> >>>>>>>>>>>>>>>>>> 00:51写道:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Ran,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks for driving the FLIP.  It
>> >>>>>>> looks
>> >>>>>>>>>>> overall
>> >>>>>>>>>>>>>>> good.
>> >>>>>>>>>>>>>>>>>> Would
>> >>>>>>>>>>>>>>>>>>>> you
>> >>>>>>>>>>>>>>>>>>>>>>> like to
>> >>>>>>>>>>>>>>>>>>>>>>>>> add
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> a description of useLike and
>> >>>>>>> notLike?
>> >>>>>>>> I
>> >>>>>>>>>>> guess
>> >>>>>>>>>>>>>>> useLike
>> >>>>>>>>>>>>>>>>>> true
>> >>>>>>>>>>>>>>>>>>>> is for
>> >>>>>>>>>>>>>>>>>>>>>>>>> "LIKE"
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> and notLike true is for "NOT LIKE"
>> >>>>>>>> but I
>> >>>>>>>>>> am
>> >>>>>>>>>>>> not
>> >>>>>>>>>>>>>>> sure
>> >>>>>>>>>>>>>>>>> if I
>> >>>>>>>>>>>>>>>>>>>>>>> understood it
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> correctly. Furthermore, does it make
>> >>>>>>>>> sense
>> >>>>>>>>>>> to
>> >>>>>>>>>>>>>>> support
>> >>>>>>>>>>>>>>>>>>> "ILIKE"
>> >>>>>>>>>>>>>>>>>>>>>> too?
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Best regards,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Jing
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Feb 22, 2023 at 1:17 PM Ran
>> >>>>>>>> Tao
>> >>>>>>>>> <
>> >>>>>>>>>>>>>>>>>>>> chucheng...@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Currently flink sql auxiliary
>> >>>>>>>>> statements
>> >>>>>>>>>>> has
>> >>>>>>>>>>>>>>>>> supported
>> >>>>>>>>>>>>>>>>>>> some
>> >>>>>>>>>>>>>>>>>>>>>> good
>> >>>>>>>>>>>>>>>>>>>>>>>>> features
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> such as catalog/databases/table
>> >>>>>>>>> support.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> But these features are not very
>> >>>>>>>>> complete
>> >>>>>>>>>>>>>> compared
>> >>>>>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>>>>> other
>> >>>>>>>>>>>>>>>>>>>>>>> popular
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> engines such as spark, presto,
>> >>>>>>> hive
>> >>>>>>>>> and
>> >>>>>>>>>>>>>>> commercial
>> >>>>>>>>>>>>>>>>>>> engines
>> >>>>>>>>>>>>>>>>>>>> such
>> >>>>>>>>>>>>>>>>>>>>>>> as
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> snowflake.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, many engines support
>> >>>>>>>> show
>> >>>>>>>>>>>>>> operation
>> >>>>>>>>>>>>>>>> with
>> >>>>>>>>>>>>>>>>>>>> filtering
>> >>>>>>>>>>>>>>>>>>>>>>>>> except
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> flink, and support describe other
>> >>>>>>>>>>>> object(flink
>> >>>>>>>>>>>>>>> only
>> >>>>>>>>>>>>>>>>>>> support
>> >>>>>>>>>>>>>>>>>>>>>>> describe
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> table).
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I wonder can we add these useful
>> >>>>>>>>>> features
>> >>>>>>>>>>>> for
>> >>>>>>>>>>>>>>>> flink?
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> You can find details in this
>> >>>>>>> doc.[1]
>> >>>>>>>>> or
>> >>>>>>>>>>>>>> FLIP.[2]
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Also, please let me know if there
>> >>>>>>>> is a
>> >>>>>>>>>>>> mistake.
>> >>>>>>>>>>>>>>>>> Looking
>> >>>>>>>>>>>>>>>>>>>> forward
>> >>>>>>>>>>>>>>>>>>>>>>> to
>> >>>>>>>>>>>>>>>>>>>>>>>>> your
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> reply.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [1]
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>
>> >>>
>> >>
>> https://docs.google.com/document/d/1hAiOfPx14VTBTOlpyxG7FA2mB1k5M31VnKYad2XpJ1I/
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> [2]
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>
>> >>>
>> >>
>> https://cwiki.apache.org/confluence/display/FLINK/FLIP-297%3A+Improve+Auxiliary+Sql+Statements
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Best Regards,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ran Tao
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>> Best regards,
>> >>>>>>>>>>>>>>> Sergey
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> --
>> >>>>>>>>>>>>> Best regards,
>> >>>>>>>>>>>>> Sergey
>> >>>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Best regards,
>> >>>>>>> Sergey
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Best regards,
>> >> Sergey
>> >>
>> >
>>
>>

Reply via email to