Kurt Young created FLINK-15879:
--
Summary: Stop overriding TableSource::getReturnType in kafka
connector
Key: FLINK-15879
URL: https://issues.apache.org/jira/browse/FLINK-15879
Project: Flink
Kurt Young created FLINK-15880:
--
Summary: Stop overriding TableSource::getReturnType in hbase
connector
Key: FLINK-15880
URL: https://issues.apache.org/jira/browse/FLINK-15880
Project: Flink
Kurt Young created FLINK-15878:
--
Summary: Stop overriding TableSource::getReturnType in tests
Key: FLINK-15878
URL: https://issues.apache.org/jira/browse/FLINK-15878
Project: Flink
Issue Type
Kurt Young created FLINK-15877:
--
Summary: Stop using deprecated methods from TableSource interface
Key: FLINK-15877
URL: https://issues.apache.org/jira/browse/FLINK-15877
Project: Flink
Issue
Would overriding `getConsumedDataType` do the job?
Best,
Kurt
On Mon, Feb 3, 2020 at 3:52 PM Zhenghua Gao wrote:
> Hi all,
>
> FLINK-12254[1] [2] updated TableSink and related interfaces to new type
> system which
> allows connectors use the new type system based on DataTypes.
>
> But
Temporal table functions is supported by both planners, feel free to use
any of them.
Best,
Kurt
Dominik Wosiński 于2020年1月21日 周二19:39写道：
> Thanksy!!
>
> I will take a look at the provided links.
> Best Regrads,
> Dom.
>
> wt., 21 sty 2020 o 12:35 Piotr Nowojski napisał(a):
>
> > In Flink
HI Xingtong,
IIRC during our tpc-ds 10T benchmark, we have suffered by JM's metaspace
size and full gc which
caused by lots of classloadings of source input split. Could you check
whether changing the default
value from 128MB to 64MB will make it worse?
Correct me if I misunderstood anything,
+1
Best,
Kurt
On Tue, Jan 7, 2020 at 2:59 PM Jingsong Li wrote:
> +1 non-binding. Thanks Forward for driving this.
>
> Considering that it is made up of independent and certain things from
> SQL standard and Calcite, I think it can be started as soon as possible.
>
> Best,
> Jingsong Lee
>
>
Hi,
+1 to the general idea. Supporting sql client gateway mode will bridge the
connection
between Flink SQL and production environment. Also the JDBC driver is a
quite good
supplement for usability of Flink SQL, users will have more choices to try
out Flink SQL
such as Tableau.
I went through
Kurt Young created FLINK-15497:
--
Summary: Topn
Key: FLINK-15497
URL: https://issues.apache.org/jira/browse/FLINK-15497
Project: Flink
Issue Type: Bug
Reporter: Kurt Young
Kurt Young created FLINK-15440:
--
Summary: Enable savepoint support for Table & SQL program
Key: FLINK-15440
URL: https://issues.apache.org/jira/browse/FLINK-15440
Project: Flink
Issue Type:
Hi Laurens,
Good to hear that you are interested with optimizing Flink's join strategy.
If you want
to learn more about the lifecycle of a query in Flink, I would
recommend you to read
the original design doc of Flink Table module [1], hope it helps.
Best,
Kurt
[1]
Congratulations Zhu Zhu!
Best,
Kurt
On Sat, Dec 14, 2019 at 10:04 AM jincheng sun
wrote:
> Congrats ZhuZhu and welcome on board!
>
> Best,
> Jincheng
>
>
> Jark Wu 于2019年12月14日周六 上午9:55写道：
>
> > Congratulations, Zhu Zhu!
> >
> > Best,
> > Jark
> >
> > On Sat, 14 Dec 2019 at 08:20, Yangze Guo
Kurt Young created FLINK-15124:
--
Summary: types with precision can't be executed in sql client with
blink planner
Key: FLINK-15124
URL: https://issues.apache.org/jira/browse/FLINK-15124
Project: Flink
Kurt Young created FLINK-15091:
--
Summary: JoinITCase.testFullJoinWithNonEquiJoinPred failed in
travis
Key: FLINK-15091
URL: https://issues.apache.org/jira/browse/FLINK-15091
Project: Flink
Kurt Young created FLINK-15073:
--
Summary: sql client fails to run same query multiple times
Key: FLINK-15073
URL: https://issues.apache.org/jira/browse/FLINK-15073
Project: Flink
Issue Type
During implementing n-ary input operator in table, please keep
this pattern in mind:
Build1 ---+
|
+---> HshJoin1 --—> HashAgg ---+
| |
Probe1 ---+ +---> HashJoin2
Kurt Young created FLINK-15066:
--
Summary: Cannot run multiple `insert into csvTable values ()`
Key: FLINK-15066
URL: https://issues.apache.org/jira/browse/FLINK-15066
Project: Flink
Issue Type
Kurt Young created FLINK-15052:
--
Summary: sql client doesn't clear previous job graph
Key: FLINK-15052
URL: https://issues.apache.org/jira/browse/FLINK-15052
Project: Flink
Issue Type: Bug
Thanks Robert for driving this. There is another big pain point of current
travis,
which is its cache mechanism will fail from time to time. Almost around 50%
of
the build fails are caused by cache problem. I opened this issue to travis
but
got no response yet. So big +1 from my side.
Just one
+1 (from my apache email ;-))
Best,
Kurt
On Wed, Dec 4, 2019 at 7:22 PM Jark Wu wrote:
> I'm +1 on this proposal.
>
> Regarding to the case that Dian mentioned, we can reminder the
> committer/PMC to vote again use the apache email,
> and of course the non-apache vote is counted as
Kurt Young created FLINK-14931:
--
Summary: ConfigOptionsDocsCompletenessITCase fails on traivs
Key: FLINK-14931
URL: https://issues.apache.org/jira/browse/FLINK-14931
Project: Flink
Issue Type
+1
Best,
Kurt
On Fri, Nov 22, 2019 at 8:51 PM Dawid Wysakowicz
wrote:
> Hi everyone,
>
> I would like to start a vote on FLIP-87.
>
> Please vote for the following design document:
> https://cwiki.apache.org/confluence/display/FLINK/FLIP+87%3A+Primary+key+constraints+in+Table+API
>
> The
+1 to disable, we also need to highlight this in 1.10 release notes.
Best,
Kurt
On Fri, Nov 22, 2019 at 5:56 PM Zhenghua Gao wrote:
> Hi,
>
> I wanted to bring up the discuss of Disable conversion between TIMESTAMP
> and Long in parameters and results of UDXs.
>
> Since FLINK-12253[1]
.
Best,
Kurt
On Thu, Nov 21, 2019 at 10:25 AM Kurt Young wrote:
> Hi Dawid,
>
> Actually I'm not 100% sure about both choices: always enforce primary key
> by Flink and not enforce at all.
>
> As you said, always enforce primary key is hard to achieve since Flink
> doesn't
> o
Kurt Young created FLINK-14887:
--
Summary: Provide a dedicated test class for SqlDateTimeUtils
Key: FLINK-14887
URL: https://issues.apache.org/jira/browse/FLINK-14887
Project: Flink
Issue Type
ints
>
>
> What do you think?
>
> Best,
>
> Dawid
>
>
> On 20/11/2019 13:51, Kurt Young wrote:
> > Hi all,
> >
> > Thanks Dawid for bringing this up, this is very important property of SQL
> > and
> > I'm big +1 to have this.
> >
Hi all,
Thanks Dawid for bringing this up, this is very important property of SQL
and
I'm big +1 to have this.
But before the discussion going deeply, I want to first mention that
according to
SQL standard, any unique key constraint which including primary key, should
be
always be enforced.
+1 (binding)
Best,
Kurt
On Wed, Nov 20, 2019 at 6:56 PM Aljoscha Krettek
wrote:
> +1 (binding)
>
> Best,
> Aljoscha
>
> > On 20. Nov 2019, at 11:36, Jingsong Li wrote:
> >
> > +1 (non-binding)
> > Thanks Jark for driving this.
> >
> > Best,
> > Jingsong Lee
> >
> > On Wed, Nov 20, 2019 at
+1 to the general idea of this FLIP.
Regarding to connector properties, IIUC it would be divided into 2 parts:
1. connector.key1 = value1, these are interpreted by Flink framework and
do whatever needed for such property.
2. connector.properties.xxx.key = value. There items are prefixed with
Kurt Young created FLINK-14694:
--
Summary: Most tests from package
o.a.f.table.planner.functions.aggfunctions are not executed during mvn test
Key: FLINK-14694
URL: https://issues.apache.org/jira/browse/FLINK-14694
Kurt Young created FLINK-14693:
--
Summary: python tox checks fails on travis
Key: FLINK-14693
URL: https://issues.apache.org/jira/browse/FLINK-14693
Project: Flink
Issue Type: Improvement
+1 (binding)
Best,
Kurt
On Sun, Nov 10, 2019 at 12:25 PM Peter Huang
wrote:
> Hi Yu,
>
> Thanks for your reminder about the timeline of delivering the basic
> function DDL in release 1.10.
> As I replied to Xuefu, the "CREATE FUNCTION" and "DROP FUNCTION" can
> relatively easy achieve by
Congrats Jark, well deserved!
Best,
Kurt
On Fri, Nov 8, 2019 at 5:53 PM Paul Lam wrote:
> Congrats Jark!
>
> Best,
> Paul Lam
>
> > 在 2019年11月8日，17:51，jincheng sun 写道：
> >
> > Hi all,
> >
> > On behalf of the Flink PMC, I'm happy to announce that Jark Wu is now
> > part of the Apache Flink
Kurt Young created FLINK-14672:
--
Summary: Make Executor stateful in sql client
Key: FLINK-14672
URL: https://issues.apache.org/jira/browse/FLINK-14672
Project: Flink
Issue Type: Improvement
Kurt Young created FLINK-14671:
--
Summary: Collaborate sql parser with sql cli
Key: FLINK-14671
URL: https://issues.apache.org/jira/browse/FLINK-14671
Project: Flink
Issue Type: Improvement
.
Best,
Kurt
On Fri, Nov 8, 2019 at 2:16 PM Terry Wang wrote:
> Hi, Kurt~
>
> Thanks for your vote and pointing out some deficiency of this flip. I’ll
> try to avoid making similar mistakes.
>
> Best,
> Terry Wang
>
>
>
> > 2019年11月8日 11:28，Kurt Young 写道：
>
Forgot to vote.. +1 from my side.
Best,
Kurt
On Fri, Nov 8, 2019 at 11:00 AM Kurt Young wrote:
> Hi all,
>
> I think we should focus to discuss the document in [DISCUSS] thread and
> keep this vote thread purely for voting.
>
> Otherwise, it's hard for others to
Hi,
Sorry to join this so late and thanks for proposing this FLIP. After
going through the proposal details, I would +1 for the changes.
However, the FLIP name is kind of confusing me. It says will do
DDL enhancement, and picked up a few new features to do. It looks
to me the goal and content of
Hi all,
I think we should focus to discuss the document in [DISCUSS] thread and
keep this vote thread purely for voting.
Otherwise, it's hard for others to collect feedbacks for this topic.
Best,
Kurt
On Thu, Nov 7, 2019 at 5:51 PM Terry Wang wrote:
> Hi Rui~
> What you suggested makes
Kurt Young created FLINK-14663:
--
Summary: Distinguish unknown column stats and zero
Key: FLINK-14663
URL: https://issues.apache.org/jira/browse/FLINK-14663
Project: Flink
Issue Type
Kurt Young created FLINK-14662:
--
Summary: Distinguish unknown table stats and zero
Key: FLINK-14662
URL: https://issues.apache.org/jira/browse/FLINK-14662
Project: Flink
Issue Type: Improvement
Kurt Young created FLINK-14608:
--
Summary: avoid using Java Streams in JsonRowDeserializationSchema
Key: FLINK-14608
URL: https://issues.apache.org/jira/browse/FLINK-14608
Project: Flink
Issue
cc @Fabian here, thought you might be interesting to review this.
Best,
Kurt
On Thu, Oct 31, 2019 at 1:39 PM Kurt Young wrote:
> Thanks Terry for bringing this up. TableEnv's interface is really critical
> not only
> to users, but also for components built upon it like SQL
Kurt Young created FLINK-14603:
--
Summary:
NetworkBufferPoolTest.testBlockingRequestFromMultiLocalBufferPool timeout in
travis
Key: FLINK-14603
URL: https://issues.apache.org/jira/browse/FLINK-14603
Thanks Terry for bringing this up. TableEnv's interface is really critical
not only
to users, but also for components built upon it like SQL CLI. Your proposal
solved some pain points we currently have, so +1 to the proposal.
I left some comments in the document.
Best,
Kurt
On Thu, Oct 31,
+1 (binding)
Best,
Kurt
On Mon, Oct 28, 2019 at 2:48 PM Jark Wu wrote:
> Thanks for driving this Danny,
>
> +1 (binding)
>
> Best,
> Jark
>
>
> On Mon, 28 Oct 2019 at 14:26, Danny Chan wrote:
>
> > Hi all,
> >
> > I would like to start the vote for FLIP-70[1] which is discussed and
> >
he reviewers for the design doc, I have resolved all the
> questions/suggestions in the doc at this time.
>
> I will kick off a voting thread shortly as there were no comments in this
> thread so far, so I would assume there are no objections :)
>
> Best,
> Danny Chan
> 在 201
t. We can add them when user
> requires.
> > Others looks good to me in general.
> >
> > Thanks,
> > Jark
> >
> >
> >> 在 2019年10月24日，14:58，Kurt Young 写道：
> >>
> >> Hi Danny,
> >>
> >> Thanks for preparing this design docu
Hi Danny,
Thanks for preparing this design document. IMO It's a very useful
feature, especially combined with time attribute support to specify
watermark in DDL.
The design doc looks quite good, but I would suggest to reduce the
scope of the first version. Like we don't have to support "STORED"
ypes are
> >> actually “known” to users, and users just want to leave them out of
> Flink
> >> type system.
> >>
> >> +1 for `RAW`, for it's more intuitive than `OPAQUE`.
> >>
> >> Best,
> >> Paul Lam
> >>
> >>> 在 20
+1 (binding)
Best,
Kurt
On Tue, Oct 22, 2019 at 12:56 AM Fabian Hueske wrote:
> +1 (binding)
>
> Am Mo., 21. Okt. 2019 um 16:18 Uhr schrieb Thomas Weise :
>
> > +1 (binding)
> >
> >
> > On Mon, Oct 21, 2019 at 7:10 AM Timo Walther wrote:
> >
> > > +1 (binding)
> > >
> > > Thanks,
> > > Timo
+1
Best,
Kurt
On Tue, Oct 15, 2019 at 9:30 AM Dawid Wysakowicz
wrote:
> Hi everyone,
> I would like to start a vote on FLIP-77.
>
> Please vote for the following design document:
>
>
> https://cwiki.apache.org/confluence/display/FLINK/FLIP-77%3A+Introduce+ConfigOptions+with+Data+Types
>
>
>
+1
- Verify that the source archives do not contains any binaries
- Start the cluster locally and ran some examples successfully
Best,
Kurt
On Mon, Oct 14, 2019 at 4:32 AM Jark Wu wrote:
> Thanks @Hequn and @Yun Tang, I set the fixVersion of FLINK-14385 to 1.8.3
> and 1.9.2.
>
> Btw, I would
+1
Best,
Kurt
On Fri, Oct 11, 2019 at 1:39 PM Dawid Wysakowicz
wrote:
> Hi everyone,
> I would like to start a vote on FLIP-64. The discussion seems to have
> reached an agreement.
>
> Please vote for the following design document:
>
>
>
row morning, unless there are some objections until then.
>
> Best,
>
> Dawid
>
>
> On 10/10/2019 16:16, Kurt Young wrote:
>
> Thanks for the clarification Timo, that's sounds good to me. Let's continue
> to discuss other things.
>
> Best,
> Kurt
>
>
> On
nd IDE support. But I agree
> that it needs some rework in the future, once we have finalized the DDL
> to ensure that both concepts are in sync.
>
> Regards,
> Timo
>
>
> On 10.10.19 16:08, Kurt Young wrote:
> > Regarding to ConnectTableDescriptor, if in the end it beco
visit that some time in the future if we
> >> find that it makes more sense.
> >>
> >> @All I updated the FLIP page with some more details from the outcome of
> >> the discussions around FLIP-57. Please take a look. I would like to
> >> start a vote on th
+1
Best,
Kurt
On Thu, Sep 26, 2019 at 11:52 AM Jark Wu wrote:
> Hi all,
>
> I would like to start the vote for FLIP-66 [1], which is discussed and
> reached a consensus in the discussion thread[2].
>
> The vote will be open for at least 72 hours. I'll try to close it after
> Oct. 01 08:00
If it's possible, I would suggest to add one sector in this doc to
emphasize that current design has a prerequisite that each job
should either has all its operators using unknown resource
profile or all using specified amount of resource. This would
make this document easier to understand.
(I
nWSdzP7GY/edit?usp=sharing
>
> Best,
> Jingsong Lee
>
> On Tue, Sep 24, 2019 at 11:43 AM Jingsong Lee
> wrote:
>
> > Thank you for your reminder.
> > Updated.
> >
> > Best,
> > Jingsong Lee
> >
> > On Tue, Sep 24, 2019 at 11:36 AM Kur
Looks like the wiki is not aligned with latest google doc, could
you update it first?
Best,
Kurt
On Tue, Sep 24, 2019 at 10:19 AM Jingsong Lee
wrote:
> Hi Flink devs, after another round of discussion.
>
> I would like to re-start the voting for FLIP-63
> Rework table partition support.
>
>
NTERVAL
> > > 'string' timeUnit".
> > > 2. Preserve Watermark From Source, the strategy can be
> > > "SYSTEM_WATERMARK()".
> > >
> > > ## Proctime Attribute
> > >
> > > CREATE TABLE table_name (
> > > ...
> &
+1 for the 1.9.1 release and for Jark being the RM.
Thanks Jark for the volunteering.
Best,
Kurt
On Mon, Sep 23, 2019 at 9:17 PM Till Rohrmann wrote:
> +1 for the 1.9.1 release and for Jark being the RM. I'll help with the
> review of FLINK-14010.
>
> Cheers,
> Till
>
> On Mon, Sep 23, 2019
+1
Best,
Kurt
On Tue, Sep 24, 2019 at 2:30 AM Bowen Li wrote:
> Hi all,
>
> I'd like to start a voting thread for FLIP-57 [1], which we've reached
> consensus in [2].
>
> This voting will be open for minimum 3 days till 6:30pm UTC, Sep 26.
>
> Thanks,
> Bowen
>
> [1]
>
>
Hi Jun,
Thanks for your understanding. If we all agree adding this functionality
into FLIP-63 is
a good idea, I would suggest you also help reviewing the FLIP-63 design
document to
see if current design meet your requirements. You can also raise some
comments to
the design document if you have
s a completely new thing, and the direct way to deal with
> >> new things is to add new grammar. So,
> >> +1 for #2, +0 for #3, -1 for #1
> >>
> >> Best,
> >> Jingsong Lee
> >>
> >>
> >> --
And let me make my vote complete:
-1 for #1
+1 for #2 with different keyword
-0 for #3
Best,
Kurt
On Thu, Sep 19, 2019 at 4:40 PM Kurt Young wrote:
> Looks like I'm the only person who is willing to +1 to #2 for now :-)
> But I would suggest to change the keyword from GLOBAL to
>
Looks like I'm the only person who is willing to +1 to #2 for now :-)
But I would suggest to change the keyword from GLOBAL to
something like BUILTIN.
I think #2 and #3 are almost the same proposal, just with different
format to indicate whether it want to override built-in functions.
My biggest
IIUC it's good to see that both serializable (tables description from DDL)
and unserializable (tables with DataStream underneath) tables are treated
unify with CatalogTable.
Can I also assume functions that either come from a function class (from
DDL)
or function objects (newed by user) will also
-SecocBqzUh7zY6HBYcfMlG_0z-JAcuZkCvsmN3LrOw/edit?ts=5d8258cd
>
> On Mon, 16 Sep 2019 at 16:12, Kurt Young wrote:
>
> > After some review and discussion in the google document, I think it's
> time
> > to
> > convert this design to a cwiki flip page and start voting process.
Hi all,
Sorry to join this party late. Big +1 to this flip, especially for the
dropping
"registerTableSink & registerTableSource" part. These are indeed legacy
and we should try to unify them through CatalogTable after we introduce
the concept of Catalog.
>From my understanding, what we can
P-63 and see if there is a better solution to
> combine these two functions. I am very willing to join this development.
>
>
>
> -- 原始邮件 --
> *发件人:* "Kurt Young";
> *发送时间:* 2019年9月17日(星期二) 中午11:19
> *收件人:* "Jun Zhang"<825875..
Kurt:
> thank you very much.
> I will take a closer look at the FLIP-63.
>
> I develop this PR, the underlying is StreamingFileSink, not
> BuckingSink, but I gave him a name, called Bucket.
>
>
> On 09/17/2019 10:57，Kurt Young
> wrote：
>
> Hi
Hi Jun,
Thanks for bringing this up, in general I'm +1 on this feature. As
you might know, there is another ongoing efforts about such kind
of table sink, which covered in newly proposed partition support
reworking[1]. In this proposal, we also want to introduce a new
file system connector, which
is?
> >
> > SQL
> > - Overview
> > - Data Manipulation Statements (all operations available in SQL)
> > - Data Definition Statements (DDL syntaxes)
> > - Pattern Matching
> >
> > It renames "Full Reference" to "Data Manipulation
t;>
>> Many of them are cases of Flink-SQL.
>>
>>
>> Best,
>>
>> Forward
>>
>> srikanth flink 于2019年9月16日周一 下午9:39写道：
>>
>> > Hi Kurt,
>> >
>> > thanks for quick response. Is the email user@ml?
>> >
>
After some review and discussion in the google document, I think it's time
to
convert this design to a cwiki flip page and start voting process.
Best,
Kurt
On Mon, Sep 9, 2019 at 7:46 PM Jark Wu wrote:
> Hi all,
>
> Thanks all for so much feedbacks received in the doc so far.
> I saw a
Hi Srikanth,
AFAIK, there are quite some companies already using Flink streaming
SQL to back their production systems, like realtime data warehouse. If
you met some issues when trying streaming sql, I would suggest you to
send the problem to user@ml, where you can receive some helps.
Best,
Kurt
+1 to this feature, I left some comments on google doc.
Another comment is I think we should do some reorganize about the content
when you converting this to a cwiki page. I will have some offline
discussion
with you.
Since this feature seems to be a fairly big efforts, so I suggest we can
+1 (binding)
- build from source and passed all tests locally
- checked the difference between 1.8.1 and 1.8.2, no legal risk found
- went through all commits checked in between 1.8.1 and 1.8.2, make
sure all the issues set the proper "fixVersion" property
Best,
Kurt
On Mon, Sep 9, 2019 at
+1 for FLIP-53.
I would like to raise one minor concern regarding to implementing
request absolute amount of memory case. Currently, it will be
translated to a memory fraction during compile, and translate back
to absolute value during execution. There is a risk that the user might
get less than
Congratulations Klou!
Best,
Kurt
On Sat, Sep 7, 2019 at 2:37 PM ying wrote:
> Congratulations Kostas!
>
> On Fri, Sep 6, 2019 at 11:21 PM Gary Yao wrote:
>
> > Congratulations Klou!
> >
> > On Sat, Sep 7, 2019 at 6:21 AM Thomas Weise wrote:
> >
> > > Congratulations!
> > >
> > >
> > > On
+1 to add JSON support to Flink. We also see lots of requirements for JSON
related functions in our internal platform. Since these are already SQL
standard, I think it's a good time to add them to Flink.
Best,
Kurt
On Thu, Sep 5, 2019 at 10:37 AM Qi Luo wrote:
> We also see strong demands
ctions, and they are up to date now.
> >>>
> >>> In short, now built-in function of external systems are defined as a
> >>> special kind of catalog function in Flink, and handled by Flink as
> >>> following:
> >>> - An external bu
Does this only affect the functions and operations we currently have in SQL
and
have no effect on tables, right? Looks like this is an orthogonal concept
with Catalog?
If the answer are both yes, then the catalog function will be a weird
concept?
Best,
Kurt
On Tue, Sep 3, 2019 at 8:10 PM Danny
Thanks Bowen for driving this.
+1 for the general idea. It makes the function resolved behavior more
clear and deterministic. Besides, the user can use all hive built-in
functions, which is a great feature.
I only have one comment, but maybe it may touch your design so I think
it would make
Thanks Xingtong for driving this effort, I haven't finished the whole
document yet,
but have couple of questions:
1. Regarding to network memory, the document said it will be derived by
framework
automatically. I'm wondering whether we should delete this dimension from
user-
facing API?
2.
+1 to the general idea and thanks for driving this. I think the new
structure is
more clear than the old one, and i have some suggestions:
1. How about adding a "Architecture & Internals" chapter? This can help
developers
or users who want to contribute more to have a better understanding about
Hi Zili,
Thanks for the proposal, I had similar confusion in the past with your
point #2.
Force rebase to master before merging can solve some problems, but it also
introduces new problem. Given the CI testing time is quite long (couple of
hours)
now, it's highly possible that before your test
one suggestion: we could also filter all notifications about *Cancelled*
builds.
Best,
Kurt
On Tue, Aug 27, 2019 at 10:53 AM jincheng sun
wrote:
> Great Job Jark :)
> Best, Jincheng
>
> Kurt Young 于2019年8月26日周一 下午6:38写道：
>
> > Thanks for the updates, Jark! I h
Kurt Young created FLINK-13867:
--
Summary: Write file only once when doing blocking broadcast shuffle
Key: FLINK-13867
URL: https://issues.apache.org/jira/browse/FLINK-13867
Project: Flink
Issue
e.html
> <
> https://ci.apache.org/projects/flink/flink-docs-stable/dev/stream/state/broadcast_state.html
> >
> [2] https://github.com/apache/flink/pull/7713 <
> https://github.com/apache/flink/pull/7713>
>
> > On 26 Aug 2019, at 09:35, Kurt Young wrote:
> >
> > F
Thanks for the updates, Jark! I have subscribed the ML and everything
looks good now.
Best,
Kurt
On Mon, Aug 26, 2019 at 11:17 AM Jark Wu wrote:
> Hi all,
>
> Sorry it take so long to get back. I have some good news.
>
> After some investigation and development and the help from Chesnay, we
>
>From SQL's perspective, distributed cross join is a valid feature but not
very
urgent. Actually this discuss reminds me about another useful feature
(sorry
for the distraction):
when doing broadcast in batch shuffle mode, we can make each producer only
write one copy of the output data, but not
on't have a pre-built version of the WebUI in the
> source.
>
> On 15/08/2019 15:22, Kurt Young wrote:
> > After going through the licenses, I found 2 suspicions but not sure if
> they
> > are
> > valid or not.
> >
> > 1. flink-state-processing-api is
-dist, but I cannot
find it in
the binary distribution of RC2.
Best,
Kurt
On Thu, Aug 15, 2019 at 6:19 PM Kurt Young wrote:
> Hi Gordon & Timo,
>
> Thanks for the feedback, and I agree with it. I will document this in the
> release notes.
>
> Best,
> Kurt
>
>
> O
Kurt Young created FLINK-13736:
--
Summary: Support count window with blink planner in batch mode
Key: FLINK-13736
URL: https://issues.apache.org/jira/browse/FLINK-13736
Project: Flink
Issue Type
Kurt Young created FLINK-13735:
--
Summary: Support session window with blink planner in batch mode
Key: FLINK-13735
URL: https://issues.apache.org/jira/browse/FLINK-13735
Project: Flink
Issue
n. We can
> > fix this in a minor release shortly after.
> >
> > What do others think?
> >
> > Regards,
> > Timo
> >
> >
> > Am 15.08.19 um 11:23 schrieb Kurt Young:
> > > HI,
> > >
> > > We just find a serious bug ar
201 - 300 of 445 matches
Mail list logo
