Hong Liang Teoh created FLINK-33073:
---
Summary: Implement end-to-end tests for the Kinesis Streams Sink
Key: FLINK-33073
URL: https://issues.apache.org/jira/browse/FLINK-33073
Project: Flink
Hong Liang Teoh created FLINK-33072:
---
Summary: Implement end-to-end tests for AWS Kinesis Connectors
Key: FLINK-33072
URL: https://issues.apache.org/jira/browse/FLINK-33072
Project: Flink
Piotr Nowojski created FLINK-33071:
--
Summary: Log checkpoint statistics
Key: FLINK-33071
URL: https://issues.apache.org/jira/browse/FLINK-33071
Project: Flink
Issue Type: New Feature
Hi Jing and Jark!
I can definitely appreciate the desire to have fewer configurations.
Do you have a suggested alternative for platform providers to limit or
restrict the hints that Bonnie is talking about?
As one possibility, maybe one configuration could be set to control all
hints.
Cheers,
Feng Jin created FLINK-33070:
Summary: Add doc for 'unnest'
Key: FLINK-33070
URL: https://issues.apache.org/jira/browse/FLINK-33070
Project: Flink
Issue Type: Improvement
Components:
Hey Martijn, thanks for picking this up.
+1 (binding)
- Release notes look good
- Sigs and checksums look good for source archive and Maven repo
- Verified there are no binaries in the source archive
- Tag exists in Github
- Reviewed website PR
- Contents of maven repo looks complete
- Source
Hey Martijn, thanks for driving this.
-1 (binding) due to the concerns highlighted below
- NOTICE files are present
- Note: The copyright year is out of data (2020)
- Concern: we bundle AnchorJS (MIT) v3.1.0 and this is not listed in the
NOTICE file
- Concern: "statefun-sdk-java" bundles
Hi Dong,
Please see my comments inline.
> As a result, the proposed job-level
> config will be applied only in the changelog stage. So there is no
> difference between these two approaches in this particular case, right?
How the job-level config can be applied ONLY in the changelog stage?
I
Hi Shammon,
Thanks for asking. @PublicEvolving is actually a very useful design that
developers can offer APIs as publicly accessible but still have changes to
introduce modifications afterwards between minor releases. Compared to it,
all @Public APIs can only be changed between major releases.
Hi Samrat,
I'm still having doubts about the dependency on the JDBC connector. When a
user specifies 'read mode', it will use the JDBC connector under the hood.
Why not integrate Redshift then directly in the JDBC connector itself? It
removes the need for a dependency on the JDBC driver,
Hi Shammon,
Thanks for the reply.
Do we really need to have `@Internal` methods in an `@Public` interface or
> class? In general, if a class or interface is marked as `@Public `, it is
> better that their public methods should also be `@Public`, because even if
> marked as `@Internal`, users are
Hi Leonard,
> Do we have to rely on the latest version of JDBC Connector here?
No, there's no need for us to depend on the latest version of the JDBC
Connector. Redshift has its dedicated JDBC driver [1], which includes
custom modifications tailored to Redshift's specific implementation needs.
Hello Danny,
I wanted to express my gratitude for your valuable feedback and insightful
suggestions.
I will be revising the FLIP to incorporate all of your queries and review
suggestions. Additionally, I plan to provide a Proof of Concept (POC) for
the connector by the end of this week. This POC
13 matches
Mail list logo