Benchao Li created FLINK-18996:
--
Summary: Avoid disorder for time interval join
Key: FLINK-18996
URL: https://issues.apache.org/jira/browse/FLINK-18996
Project: Flink
Issue Type: Improvement
Rui Li created FLINK-18995:
--
Summary: Some Hive functions fail because they need to access
SessionState
Key: FLINK-18995
URL: https://issues.apache.org/jira/browse/FLINK-18995
Project: Flink
Issue
Thanks Fabian and Seth for the feedback
I agree the name “temporal table without version” is less accurate because this
kind of temporal table has a latest version rather than has no version.
How about “Latest-only temporal table” ? The related concept section updated as
following:
Temporal
Peng created FLINK-18994:
Summary: There is one typo in "Set up TaskManager Memory"
Key: FLINK-18994
URL: https://issues.apache.org/jira/browse/FLINK-18994
Project: Flink
Issue Type: Improvement
Peng created FLINK-18993:
Summary: Invoke sanityCheckTotalFlinkMemory method incorrectly in
JobManagerFlinkMemoryUtils.java
Key: FLINK-18993
URL: https://issues.apache.org/jira/browse/FLINK-18993
Project:
tzxxh created FLINK-18992:
-
Summary: Table API renameColumns method annotation error
Key: FLINK-18992
URL: https://issues.apache.org/jira/browse/FLINK-18992
Project: Flink
Issue Type: Bug
+1 to the updated design.
I agree with Fabian that the naming of "temporal table without version" is
a bit confusing but the actual semantics make sense to me. I think just
saying its a Flink managed lookup join makes sense.
Seth
On Tue, Aug 18, 2020 at 3:07 PM Fabian Hueske wrote:
> Thanks
Thanks for the updated FLIP Leonard!
In my opinion this was an improvement.
So +1 for this design.
I have just one remark regarding the terminology.
I find the term "Temporal Table without Version" somewhat confusing.
IMO, versions are the core principle of temporal tables and temporal tables
Being able to optionally fire registered processing time timers at the end
of a job would be interesting, and would help in (at least some of) the
cases I have in mind. I don't have a better idea.
David
On Mon, Aug 17, 2020 at 8:24 PM Kostas Kloudas wrote:
> Hi Kurt and David,
>
> Thanks a lot
Roman Khachatryan created FLINK-18991:
-
Summary: Optimize reading InputChannel state
Key: FLINK-18991
URL: https://issues.apache.org/jira/browse/FLINK-18991
Project: Flink
Issue Type:
Roman Khachatryan created FLINK-18990:
-
Summary: Optimize reading ResultSubpartition state
Key: FLINK-18990
URL: https://issues.apache.org/jira/browse/FLINK-18990
Project: Flink
Issue
Roman Khachatryan created FLINK-18989:
-
Summary: Write input and output channel state to separate files
Key: FLINK-18989
URL: https://issues.apache.org/jira/browse/FLINK-18989
Project: Flink
+1 (non-binding)
- checksum & signatures, OK
- build from source, OK
- ran some example jobs on clusters, OK
- all pom files point to 1.10.2
- NOTICE/LICENSE files seem OK
Best,
Congxian
Till Rohrmann 于2020年8月18日周二 下午5:24写道：
> +1 (binding)
>
> - verified checksums and signatures
> - verified
Fabian Hueske created FLINK-18988:
-
Summary: Continuous query with LATERAL and LIMIT produces wrong
result
Key: FLINK-18988
URL: https://issues.apache.org/jira/browse/FLINK-18988
Project: Flink
+1 (binding)
- checked release notes ✅
- verified signatures and checksums ✅
- reviewed website PR ✅
- built an internal Flink distribution from source ✅
- built internal jobs against the staging repo ✅
- deployed a job cluster on Kubernetes and tested checkpointing ✅
- tested fix for FLINK-18902
Chesnay Schepler created FLINK-18987:
Summary: Sort global job parameters in WebUI job configuration view
Key: FLINK-18987
URL: https://issues.apache.org/jira/browse/FLINK-18987
Project: Flink
Hi Yun and Dawid,
Dawid is correct in that:
```
BATCH = pipelined scheduling with region failover + blocking keyBy
shuffles (all pointwise shuffles pipelined)
STREAM = eager scheduling with checkpointing + pipelined keyBy shuffles
AUTOMATIC = choose based on sources (ALL bounded == BATCH,
Hi all,
@Klou Nice write up. One comment I have is I would suggest using a
different configuration parameter name. The way I understand the
proposal the BATCH/STREAMING/AUTOMATIC affects not only the scheduling
mode but types of shuffles as well. How about `execution.mode` ? Or
Chesnay Schepler created FLINK-18986:
Summary: KubernetesSessionCli creates RestClusterClient for
detached deployments
Key: FLINK-18986
URL: https://issues.apache.org/jira/browse/FLINK-18986
+1 (binding)
- verified checksums and signatures
- verified that dependency changes are reflected in NOTICE/LICENSE files
- built Flink with Scala 2.12 support from sources
- Started cluster and ran example jobs, no suspicious log output
Cheers,
Till
On Mon, Aug 17, 2020 at 4:21 PM Jeff Zhang
Hequn Cheng created FLINK-18985:
---
Summary: Update the Sphinx doc for Python DataStream API.
Key: FLINK-18985
URL: https://issues.apache.org/jira/browse/FLINK-18985
Project: Flink
Issue Type:
Hequn Cheng created FLINK-18984:
---
Summary: Add tutorial documentation for Python DataStream API
Key: FLINK-18984
URL: https://issues.apache.org/jira/browse/FLINK-18984
Project: Flink
Issue
YufeiLiu created FLINK-18983:
Summary: Job doesn't changed to failed if close function has
blocked
Key: FLINK-18983
URL: https://issues.apache.org/jira/browse/FLINK-18983
Project: Flink
Issue
Having looked at the proposed set of methods to remove I've noticed that
some of them are actually annotated with @Public. According to our
stability guarantees, only major releases (1.0, 2.0, etc.) can break APIs
with this annotation. Hence, I believe that we cannot simply remove them
unless the
24 matches
Mail list logo
