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
>>> 
> 


Reply via email to