Thanks everyone, it's always great to collaborate with you guys, look forward
to contribute more on Flink.
Thanks
Chengxiang
-Original Message-
From: Paris Carbone [mailto:par...@kth.se]
Sent: Tuesday, January 19, 2016 9:24 PM
To: dev@flink.apache.org
Subject: Re: [ANNOUNCE] Chengxiang
+1 on the original style.
Master branch disable force pushing in case of misusing and feature branch
enable force pushing for flexible developing.
-Original Message-
From: Gyula Fóra [mailto:gyf...@apache.org]
Sent: Wednesday, January 13, 2016 6:36 PM
To: dev@flink.apache.org
Subject: Re
Very cool work, look forward to contribute.
-Original Message-
From: Chiwan Park [mailto:chiwanp...@apache.org]
Sent: Friday, January 8, 2016 9:36 AM
To: dev@flink.apache.org
Subject: Re: Effort to add SQL / StreamSQL to Flink
Really good! Many people want to use SQL. :)
> On Jan 8, 201
ystem.
Thanks
Chengxiang
-Original Message-
From: Li, Chengxiang [mailto:chengxiang...@intel.com]
Sent: Thursday, December 3, 2015 4:43 PM
To: dev@flink.apache.org
Subject: RE: The null in Flink
Hi, Stephan
Treat UNKOWN as FALSE may works if the Boolean expression is used in filter
operation
whole term becomes UNKNOWN and
the row is filtered out (as if the predicate was false) - the result of the
query contains no rows where predicate results are UNKNOWN.
Stephan
On Tue, Dec 1, 2015 at 4:09 AM, Li, Chengxiang
wrote:
> Stephen,
> For the 3rd topic, you mentioned
UNKNOWN value can be the same as FALSE. So the query planner had to
>> rewrite all expression trees to have no NOT, which means pushing the
>> NOT down into the leaf comparison operations (for example push NOT into ==
>> to become !=).
>> These leaf comparison operators needed to
top of the Table API.
Regards,
Timo
On 25.11.2015 11:31, Li, Chengxiang wrote:
> Hi
> In this mail list, there are some discussions about null value handling in
> Flink, and I saw several related JIRAs as well(like FLINK-2203, FLINK-2210),
> but unfortunately, got reverted due to imm
Hi
In this mail list, there are some discussions about null value handling in
Flink, and I saw several related JIRAs as well(like FLINK-2203, FLINK-2210),
but unfortunately, got reverted due to immature design, and no further action
since then. I would like to pick this topic up here, as it's qu
skew! I agree, it's a
> important issue that can cause a lot of problems.
> I'll have a look at your proposal and add comments soon.
>
> Thanks, Fabian
>
> 2015-10-15 12:24 GMT+02:00 Li, Chengxiang :
>
>> Dear all,
>> In many real world use case, data are
Dear all,
In many real world use case, data are nature to be skewed. For example, in
social network, famous people get much more "follow" than others, a hot tweet
would be transferred millions of times. and the purchased records of normal
product can never compared to hot products. While at the
microbenchmarks with test execution. The code
for these benchmarks resides in the test scope of the projects (so it is not
packaged), but it is not executed as part of the UnitTests or IntegrationTests.
Greetings,
Stephan
On Tue, Sep 22, 2015 at 12:22 PM, Li, Chengxiang
wrote:
> Hi, folks
>
Found more KafkaITCase failure at:
https://travis-ci.org/apache/flink/jobs/81592146
Failed tests:
KafkaITCase.testConcurrentProducerConsumerTopology:50->KafkaConsumerTestBase.runSimpleConcurrentProducerConsumerTopology:334->KafkaTestBase.tryExecute:313
Test failed: The program execution fail
Hi, folks
During work on Flink, I found several micro benchmarks which come from
different modules, these benchmarks measure on manual, annotated with Junit
annotations, so they got executed during unit test as well. There are some
shortage on current implementation:
1. Benchmark test per
Hi, flink developers
I read the flink hybrid hash join documents and implementation, very nice job.
For the case of small table does not all fit into memory, I think we may able
to improve the performance better. Currently in hybrid hash join, while small
table does not fit into memory, part o
14 matches
Mail list logo
