Re: [DISCUSS] Flink SQL DDL Design

2018-12-09 Thread Lin Li
specify it. If it is only a readable table, an > > >> exception can be thrown when write to it. As the source/sink tag can > be > > >> omitted in CREATE TABLE, could we skip it and only support CREATE > TABLE > > in > > >> the first version, and add it b

Re: [DISCUSS] Flink SQL DDL Design

2018-12-07 Thread Lin Li
sed for? > >>>>>>>> > >>>>>>>> > >>>>>>>> The features could be supported and discussed in the future: > >>>>>>>> (1) period definition on table > >>>>>>>> (2) Type DDL > >>>&

Re: [DISCUSS] Flink SQL DDL Design

2018-12-05 Thread Lin Li
gt;> I think summarizing it into a google doc is a good idea. We > >> will > >>>>>> prepare > >>>>>>> it > >>>>>>>> in the next few days. > >>>>>>>> > >>>>>

Re: [DISCUSS] Flink SQL DDL Design

2018-11-28 Thread Lin Li
this field > > > should > > > > already exist in the schema (we can use computed-column to derive > from > > > > other fields). The “AS” keyword defines watermark strategy, such as > > > BOUNDED > > > > WITH OFFSET (covers almost all the requirements) and AS

Re: [DISCUSS] Flink SQL DDL Design

2018-11-28 Thread Lin Li
@Shuyi Thanks for the proposal! We have a simple DDL implementation (extends Calcite's parser) which been running for almost two years on production and works well. I think the most valued things we'd learned is keeping simplicity and standard compliance. Here's the approximate grammar, FYI CREATE

Re: How to Join a dimension table in flink sql

2018-01-15 Thread Lin Li
Hi XiangWei, Currently one could implement a udtf to achieve that. (see https://ci.apache.org/projects/flink/flink-docs-release-1.4/dev/table/udfs. html#table-functions) BTW, this udtf should carefully dealing with the connections to database server(s), and enable caching if possible can reduce se

dev@flink.apache.org

2017-07-30 Thread Lin Li
Hi everybody, I'd like to propose and discuss some api changes to support DML operations like ‘insert into’ clause in TableAPI&SQL. Originally this was discussed with Fabian in the PR conversations(see https://github.com/apache/flink/pull/3829), considering it makes several api changes, so star

Re: [DISCUSS] Should we supply a new Iterator instance for Functions with Iterable input(s) like CoGroupFunction ?

2017-02-22 Thread Lin Li
. Please go > ahead and open an issue for re-adding the throw. > > On Wed, 22 Feb 2017 at 13:28 Lin Li wrote: > > > Thank you for the answer! > > > > The discussion on FLINK-1023 is very clear to me. I agree with that > throws > > a TraversableOnceExceptio

Re: [DISCUSS] Should we supply a new Iterator instance for Functions with Iterable input(s) like CoGroupFunction ?

2017-02-22 Thread Lin Li
Thank you for the answer! The discussion on FLINK-1023 is very clear to me. I agree with that throws a TraversableOnceException when the iterator is requested the second time. @Aljoscha git history shows you removed the exception-thrown code from FLINK-1110, would you mind me create an issue and

[DISCUSS] Should we supply a new Iterator instance for Functions with Iterable input(s) like CoGroupFunction ?

2017-02-21 Thread Lin Li
Hi, When I try to implement https://issues.apache.org/jira/browse/FLINK-5498 via "dataset.coGroup(another dataset)" with a generated CoGroupFunction.(CoGroupFunction interface: public void coGroup(Iterable first, Iterable second, Collector out) I couldn't get the right results, then I sa