Dian Fu created FLINK-19422:
---
Summary: Avro Confluent Schema Registry nightly end-to-end test
failed with "Register operation timed out; error code: 50002"
Key: FLINK-19422
URL:
Dian Fu created FLINK-19421:
---
Summary: Support Python UDAF in streaming mode
Key: FLINK-19421
URL: https://issues.apache.org/jira/browse/FLINK-19421
Project: Flink
Issue Type: Sub-task
Hi Chesnay,
Thanks, and you were right - it wasn’t a case of too many memory segments
triggering too many open files.
It was a configuration issue with Elasticsearch clients being used by a custom
function. This just happened to start being executed at the same time as the
leftOuterJoin &
Hi, Jark,
I'm very interested in this feature, and I'm also working on this
recently.
I just have a glance at the FLIP, it's good, but I found that there is
no plan to add SESSION windows.
Also, I think there can be more things we can do based on this new
syntax. For
Hi everyone,
I want to start a FLIP about supporting windowing table-valued functions
(TVF).
The main purpose of this FLIP is to improve the near real-time (NRT)
experience of Flink.
FLIP-145:
Xiao Huang created FLINK-19420:
--
Summary: Translate "Program Packaging" page of "Managing
Execution" into Chinese
Key: FLINK-19420
URL: https://issues.apache.org/jira/browse/FLINK-19420
Project: Flink
Congrats to everyone involved !
Etienne
On 21/09/2020 08:34, Yu Li wrote:
Thanks Zhu Zhu for being our release manager and everyone else who made the
release possible!
Best Regards,
Yu
On Thu, 17 Sep 2020 at 13:29, Zhu Zhu wrote:
The Apache Flink community is very happy to announce the
I should clarify my last email a little more.
For the example of commits for checkpoints 1-100 failed, the job is still
up (processing records and uploading files). When commit for checkpoint 101
came, IcebergSink would prefer the framework to pass in all 101 GlobalCommT
(100 old + 1 new) so that
Thank you Julian for mentioning the anti-join. With its help, I managed to
solve our particular case similarly as follows:
```
SELECT e.*
FROM events e
LEFT JOIN patterns p
ON e.record_id = p.begin_record_id
WHERE e.pattern_val = 'BEGIN' AND p.begin_record_id is null
```
However, I'm thinking
CaoZhen created FLINK-19419:
---
Summary: "null-string-literal" does not work in HBaseSource
decoder
Key: FLINK-19419
URL: https://issues.apache.org/jira/browse/FLINK-19419
Project: Flink
Issue
Done
Seth
On Fri, Sep 25, 2020 at 2:47 AM Yu Li wrote:
> *bq. I think it might help to highlight specific stumbling blocks users
> have today and why I believe this change addresses those issues.*
> Thanks for adding more details, I believe adding these blocks to the FLIP
> doc could make the
> 1. The frame can not know which `GlobalCommT` to retry if we use the
> List as parameter when the `commit` returns `RETRY`.
> 2. Of course we can let the `commit` return more detailed info but it
might
> be too complicated.
If commit(List) returns RETRY, it means the whole list needs
to be
Konstantin Knauf created FLINK-19418:
Summary: Inline PRIMARY KEY constraint should be invalid
Key: FLINK-19418
URL: https://issues.apache.org/jira/browse/FLINK-19418
Project: Flink
+1 (binding)
Aljoscha
On 25.09.20 14:26, Guowei Ma wrote:
From the discussion[1] we could find that FLIP focuses on providing an
unified transactional sink API. So I updated the FLIP's title to "Unified
Transactional Sink API". But I found that the old link could not be opened
again.
I would
Hi everyone,
Thanks for the proposal.
In our company,we meet the same situation as @liu shouwei.
We developed some features base on flink.Such as parallelism of sql source/sink
connector, and kafka delay consumer which is adding a flatmap and a keyby
transformation after the source Datastream.
>From the discussion[1] we could find that FLIP focuses on providing an
unified transactional sink API. So I updated the FLIP's title to "Unified
Transactional Sink API". But I found that the old link could not be opened
again.
I would update the link[2] here. Sorry for the inconvenience.
[1]
Hi, all
>From the above discussion we could find that FLIP focuses on providing an
unified transactional sink API. So I updated the FLIP's title to "Unified
Transactional Sink API". But I found that the old link could not be opened
again.
I would update the link[1] here. Sorry for the
Huang Xingbo created FLINK-19417:
Summary: Fix the bug of the method from_data_stream in
table_environement
Key: FLINK-19417
URL: https://issues.apache.org/jira/browse/FLINK-19417
Project: Flink
Hi,
I understand from your email that
`StreamExecutionEnvironment.registerJobListener()` would not be enought
for you because you want to be notified of changes on the cluster side,
correct? That is when the job status changes on the master.
Best,
Aljoscha
On 23.09.20 14:31, 季文昊 wrote:
Hi
Huang Xingbo created FLINK-19416:
Summary: Support Python datetime object in from_collection of
Python DataStream
Key: FLINK-19416
URL: https://issues.apache.org/jira/browse/FLINK-19416
Project:
Thanks for starting this discussion, Yangze.
My personal preference for either singleton or non-initiatable classes is
to use enum wherever it is possible, because it's briefer is safer. On the
other hand, I'm also against private constructors.
To my understanding, for most if not all
Thanks all for the valuable feedbacks!
@Gael @Dawid
Thanks for the explanation! I think you are right that this discussion
is about a non-instantiable class that contains only static methods.
@All
My major proposal is actually to stick to one of two approaches in
Flink. It seems that most devs
Hi, thanks for starting this discussion.
I am +1 for using the private constructor for util class. We don't need to
change it.
I think few libraries use the enum, such as guava, common-utils, or even
JDK, the private constructor is widely used.
I don't quite understand why a util class is an
Hi all,
First of all I very much agree with Gael. The discussion is not about a
Singleton pattern.
Secondly, similarly as @Timo and @Gael I find the pattern very
confusing. Each time I see it I have a hard time figuring out why there
are no enumerations in the enum. This is my preference though.
Hi
One small remark here: you should not call this a Singleton. For most
people, a Singleton would refer to the implementation of the GoF Singleton
pattern, where you have a single instance of the class (see for instance
the corresponding Wikipedia page:
Hi,
honstely, I find using enums is more of a hack. `enum` stands for
enumeration and is meant for listing flags or options. Using it for
singleton patterns is just abusing a concept due to certain
implementation details and less code.
I feel this topic is like using Lombok for generating
+1 (binding)
- build from the source and run all tests (successfully)
- verified pom files between release-2.1 and release-2.2 branches for any
relevant licensing changes
Piotrek
pt., 25 wrz 2020 o 10:21 Tzu-Li (Gordon) Tai
napisał(a):
> +1 (binding)
>
> - Verified signatures, and no binaries
Jingsong Lee created FLINK-19415:
Summary: Move Hive document to "Table & SQL Connectors" from
"Table API & SQL"
Key: FLINK-19415
URL: https://issues.apache.org/jira/browse/FLINK-19415
Project: Flink
Thanks for your feedback.
I created https://issues.apache.org/jira/browse/FLINK-19415 for track this.
Best,
Jingsong
On Fri, Sep 25, 2020 at 11:11 AM Leonard Xu wrote:
> +1
>
> > 在 2020年9月24日，21:54，Seth Wiesman 写道：
> >
> > +1
> >
> > On Thu, Sep 24, 2020 at 2:49 AM Rui Li wrote:
> >
> >> +1
Hi,
I don't mind one way or the other.
I guess enum way is somehow safer, however did we really have any issues
with our current approach with `private` constructors? I mean, you are
mentioning that using reflections could overcome private constructors, but
is that a real concern in our code
Jingsong Lee created FLINK-19414:
Summary: Introduce ParquetColumnarRowInputFormat
Key: FLINK-19414
URL: https://issues.apache.org/jira/browse/FLINK-19414
Project: Flink
Issue Type: Sub-task
Hi, devs,
Recently, in the PR of FLINK-19179[1], we have a discussion about how
to implement singleton pattern in Flink.
Currently, most of the utility classes implement singleton pattern
through the private constructor. Seldom utility classes leverage the
enum mechanism. From my perspective,
+1 (binding)
- Verified signatures, and no binaries in release artifacts
- Built from source
- Built Docker image from Dockerfiles in
https://github.com/apache/flink-statefun-docker/pull/10.
- Ran E2E tests with the built Dockerfiles (both Java 8 and 11 variants)
- Ran the Python Greeter Example
Hi Jingsong,
Thanks for driving this effort. I have two minor comments.
1. IMHO, parallelism is a concept that applies to all ScanTableSource.
So instead of defining a new interface, is it more natural to incorporate
parallel inference to existing interfaces, e.g. ScanTableSource
or
weizheng created FLINK-19413:
Summary: Translate "FileSystem" page of "Table & SQL Connectors"
into Chinese
Key: FLINK-19413
URL: https://issues.apache.org/jira/browse/FLINK-19413
Project: Flink
Huang Xingbo created FLINK-19412:
Summary: Re-layer Python Operation Make it Possible to Provide
only Python implementation
Key: FLINK-19412
URL: https://issues.apache.org/jira/browse/FLINK-19412
*bq. I think it might help to highlight specific stumbling blocks users
have today and why I believe this change addresses those issues.*
Thanks for adding more details, I believe adding these blocks to the FLIP
doc could make the motivation more vivid and convincing.
*bq. To be concrete I think
Caizhi Weng created FLINK-19411:
---
Summary: MultipleInputStreamTask fails with RuntimeException when
its input contains union
Key: FLINK-19411
URL: https://issues.apache.org/jira/browse/FLINK-19411
Hi Aljoscha,
Thank you for your feedback,
## Connector parallelism
Requirements:
Set parallelism by user specified or inferred by connector.
How to configure parallelism in DataStream:
In the DataStream world, the only way to configure parallelism is
Hi, Steven
>>I also have a clarifying question regarding the WriterStateT. Since
>>IcebergWriter won't need to checkpoint any state, should we set it to
*Void*
>>type? Since getWriterStateSerializer() returns Optional, that is clear and
>>we can return Optional.empty().
Yes I think you could do
Matthias created FLINK-19410:
Summary: RestAPIStabilityTest does not assert on enum changes
Key: FLINK-19410
URL: https://issues.apache.org/jira/browse/FLINK-19410
Project: Flink
Issue Type: Bug
Hi,Steven
Thank you for reading the FLIP so carefully.
1. The frame can not know which `GlobalCommT` to retry if we use the
List as parameter when the `commit` returns `RETRY`.
2. Of course we can let the `commit` return more detailed info but it might
be too complicated.
3. On the other hand, I
+1
On Wed, Sep 23, 2020 at 9:13 AM Yu Li wrote:
> +1
>
> Best Regards,
> Yu
>
>
> On Tue, 22 Sep 2020 at 17:49, Robert Metzger wrote:
>
> > No concerns from my side.
> >
> > On Fri, Sep 18, 2020 at 8:25 AM Chesnay Schepler
> > wrote:
> >
> > > Hello,
> > >
> > > I'd like to kickoff the next
Liu created FLINK-19409:
---
Summary: The comment for getValue has wrong code in class ListView
Key: FLINK-19409
URL: https://issues.apache.org/jira/browse/FLINK-19409
Project: Flink
Issue Type:
Tzu-Li (Gordon) Tai created FLINK-19408:
---
Summary: Update flink-statefun-docker release scripts for cross
release Java 8 and 11
Key: FLINK-19408
URL: https://issues.apache.org/jira/browse/FLINK-19408
45 matches
Mail list logo
