Hi all,
I also think it's a good idea that we need to agree on the API level first.
I am sorry, we did not give some usage examples of the API in the FLIP
documentation before. This may have caused some misunderstandings about the
discussion of this mail thread.
So, now I have added some usage
Hi Jark,
`DataStream.localKeyBy().process()` has some key difference with
`DataStream.process()`. The former API receive `KeyedProcessFunction`
(sorry my previous reply may let you misunderstood), the latter receive API
receive `ProcessFunction`. When you read the java doc of ProcessFunction,
you
sunjincheng created FLINK-13011:
---
Summary: Release the PyFlink into PyPI
Key: FLINK-13011
URL: https://issues.apache.org/jira/browse/FLINK-13011
Project: Flink
Issue Type: Sub-task
zhijiang created FLINK-13010:
Summary: Refactor the process of SchedulerNG#requestPartitionState
Key: FLINK-13010
URL: https://issues.apache.org/jira/browse/FLINK-13010
Project: Flink
Issue
Congxian Qiu(klion26) created FLINK-13009:
-
Summary:
YARNSessionCapacitySchedulerITCase#testVCoresAreSetCorrectlyAndJobManagerHostnameAreShownInWebInterfaceAndDynamicPropertiesAndYarnApplicationNameAndTaskManagerSlots
wangpeibin created FLINK-13008:
--
Summary: fix the findbugs warning in AggregationsFunction
Key: FLINK-13008
URL: https://issues.apache.org/jira/browse/FLINK-13008
Project: Flink
Issue Type:
Hi Piotr,
I think the state migration you raised is a good point. Having
"stream.enableLocalAggregation(Trigger)” might add some implicit operators
which users can't set uid and cause the state compatibility/evolution
problems.
So let's put this in rejected alternatives.
Hi Vino,
You mentioned
Bowen Li created FLINK-13007:
Summary: Integrate Flink's FunctionCatalog with Catalog APIs
Key: FLINK-13007
URL: https://issues.apache.org/jira/browse/FLINK-13007
Project: Flink
Issue Type:
+1 for sticking to the lazy majority voting.
A question from my side, the 3+1 votes are binding votes which only active
(i.e. non-emeritus) committers and PMC members have?
Best,
Jark
On Wed, 26 Jun 2019 at 19:07, Tzu-Li (Gordon) Tai
wrote:
> +1 to enforcing lazy majority voting for future
Bowen Li created FLINK-13006:
Summary: remove GenericUDTFReplicateRows from GenericUDTFTest
because Hive 1.2.1 doesn't have it
Key: FLINK-13006
URL: https://issues.apache.org/jira/browse/FLINK-13006
Bowen Li created FLINK-13005:
Summary: HiveCatalog should not add 'flink.is_generic' key for
Hive table
Key: FLINK-13005
URL: https://issues.apache.org/jira/browse/FLINK-13005
Project: Flink
just elaborate a bit more on why slow build is ok but no resource is not: Say I
submit a build request at PST 9am, no other requests exist and mine is the
queue head, currently it means it still cannot get built until 4 or 5pm.
> On Jun 26, 2019, at 12:28, Bowen Li wrote:
>
> Hi,
>
>
Hi,
@Dawid, I think the "long test running" as I mentioned in the first email,
also as you guys said, belongs to "a big effort which is much harder to
accomplish in a short period of time and may deserve its own separate
discussion". Thus I didn't include it in what we can do in a foreseeable
Yun Tang created FLINK-13004:
Summary: Correct the logic of needToCleanupState in
KeyedProcessFunctionWithCleanupState
Key: FLINK-13004
URL: https://issues.apache.org/jira/browse/FLINK-13004
Project:
Hi all,
As a gentle reminder, the meetup [1] will be on today at 6:30pm at Zendesk,
1019 Market Street, SF. Come on in for enlightening talks as well as foods
and drinks.
See you there!
Regards,
Xuefu
[1] https://www.meetup.com/Bay-Area-Apache-Flink-Meetup/events/262216929/
On Fri, Jun 21,
Jark Wu created FLINK-13003:
---
Summary: Support Temporal TableFunction Join in processing time
and event time
Key: FLINK-13003
URL: https://issues.apache.org/jira/browse/FLINK-13003
Project: Flink
Konstantin Knauf created FLINK-13002:
Summary: Expand Concept -> Glossary Section
Key: FLINK-13002
URL: https://issues.apache.org/jira/browse/FLINK-13002
Project: Flink
Issue Type:
Congratulations Jincheng!
Best,
Danny Chan
在 2019年6月24日 +0800 PM11:09，dev@flink.apache.org，写道：
>
> Congratulations Jincheng!
Chesnay Schepler created FLINK-13001:
Summary: Add ExecutionGraphBuilder for testing
Key: FLINK-13001
URL: https://issues.apache.org/jira/browse/FLINK-13001
Project: Flink
Issue Type:
Thanks for the updates so far everyone!
Since support for the new Blink-based Table / SQL runner and fine-grained
recovery are quite prominent features for 1.9.0,
and developers involved in these topics have already expressed that these
could make good use for another week,
I think it definitely
+1 to enforcing lazy majority voting for future FLIPs, starting from FLIPs
that are still currently under discussion (by the time we've agreed on the
FLIP voting process).
My two cents concerning "what should and shouldn't be a FLIP":
I can understand Chesnay's argument about how some FLIPs,
Chesnay Schepler created FLINK-13000:
Summary: Remove JobID argument from SimpleSlotProvider
Key: FLINK-13000
URL: https://issues.apache.org/jira/browse/FLINK-13000
Project: Flink
Issue
Zhenghua Gao created FLINK-12999:
Summary: Can't generate valid execution plan for "SELECT uuid()
FROM VALUES(1) T(a)"
Key: FLINK-12999
URL: https://issues.apache.org/jira/browse/FLINK-12999
Project:
Piotr Nowojski created FLINK-12998:
--
Summary: Document Plugins mechanism.
Key: FLINK-12998
URL: https://issues.apache.org/jira/browse/FLINK-12998
Project: Flink
Issue Type: Sub-task
Chesnay Schepler created FLINK-12997:
Summary: Release partitions for reset vertices
Key: FLINK-12997
URL: https://issues.apache.org/jira/browse/FLINK-12997
Project: Flink
Issue Type:
Hi Jark and Vino,
I agree fully with Jark, that in order to have the discussion focused and to
limit the number of parallel topics, we should first focus on one topic. We can
first decide on the API and later we can discuss the runtime details. At least
as long as we keep the potential
Hi Aljoscha,
Thanks for bringing up this discussion! :)
+1 for sticking with “lazy majority” of approvals!
At the same time, we should create the FLIP boundary from the new
definition, i.e. which kind of change must create FLIP. The content of the
current [1] description is relatively old. For
I'm not entirely sure, but you could try writing your configuration into
the ExecutionConfig using ExEnv#getExecutionConfig#setGlobalJobParameters.
IIRC this should then show up under /jobs/:jobid/config .
On 26/06/2019 12:04, Dominik Wosiński wrote:
Hey,
I am building jobs that use
Hey,
I am building jobs that use Typesafe Config under the hood. The configs
tend to grow big. I was wondering whether there is a possibility to use
WebUI to show the config that the job was run with, currently the only idea
is to log the config and check it inside the logs, but with dozens of
The FLIP guidelines disagree with your first point.
The guidelines are a bit contradictory as at some places we say that
FLIPs are for major features, and in other places say they are for any
changes to the public API.
This very point came up in the recent FLIP about standardizing metrics.
Timo Walther created FLINK-12996:
Summary: Add predefined type validators, strategies, and
transformations
Key: FLINK-12996
URL: https://issues.apache.org/jira/browse/FLINK-12996
Project: Flink
Hi All,
When we originally introduced the FLIP process (which is based on the KIP
process from Kafka and refers to the Kafka bylaws for how votes work) voting
was set to be “lazy majority”. This means that a FLIP vote "requires 3 binding
+1 votes and more binding +1 votes than -1 votes”
Hi Jincheng,
Thanks for raising the discussion!
The key information is very important for query optimizations. It would be
nice if we can use upsert mode to achieve better performance.
+1 for the `withKeys` proposal. :)
Best, Hequn
On Wed, Jun 26, 2019 at 4:37 PM jincheng sun
wrote:
> Hi
Rui Li created FLINK-12995:
--
Summary: Add Hive-1.2.1 build to Travis
Key: FLINK-12995
URL: https://issues.apache.org/jira/browse/FLINK-12995
Project: Flink
Issue Type: Sub-task
Hi all,
With the continuous efforts from the community, we already supported
`flatAggregate`[1] on TableAPI in retract mode. I think It's better to add
upsert mode for `flatAggregate`.
The result table of streaming non-window `flatAggregate` is a table
contains updates. We can, of course, use a
Congxian Qiu(klion26) created FLINK-12994:
-
Summary: Improve the buffer processing performance in
SpilledBufferOrEventSequence#getNext
Key: FLINK-12994
URL:
Chesnay Schepler created FLINK-12993:
Summary: Rework forceReleaseOnConsumptionFlag to be JM internal
concept
Key: FLINK-12993
URL: https://issues.apache.org/jira/browse/FLINK-12993
Project:
Sorry to jump in late, but I think Bowen missed the most important point
from Chesnay's previous message in the summary. The ultimate reason for
all the problems is that the tests take close to 2 hours to run already.
I fully support this claim: "Unless people start caring about test times
before
Do we know if using "the best" available hardware would improve the build
times?
Imagine we would run the build on machines with plenty of main memory to
mount everything to ramdisk + the latest CPU architecture?
Throwing hardware at the problem could help reduce the time of an
individual build,
From what I gathered, there's no special sauce that the Zeppelin
project uses which actually integrates a users Travis account into the PR.
They just disabled Travis for PRs. And that's kind of it.
Naturally we can do this (duh) and safe the ASF a fair amount of
resources, but there are
Hi Jark,
Similar questions and responses have been repeated many times.
Why didn't we spend more sections discussing the API?
Because we try to reuse the ability of KeyedStream. The localKeyBy API just
returns the KeyedStream, that's our design, we can get all the benefit from
the KeyedStream
yanxiaobin created FLINK-12992:
--
Summary: All host(s) tried for query failed (tried
com.datastax.driver.core.exceptions.TransportException: Error writing...)
Key: FLINK-12992
URL:
Dian Fu created FLINK-12991:
---
Summary: Correct the implementation of Catalog.get_table_factory
Key: FLINK-12991
URL: https://issues.apache.org/jira/browse/FLINK-12991
Project: Flink
Issue Type:
43 matches
Mail list logo
