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