leekeiabstraction commented on code in PR #188:
URL:
https://github.com/apache/flink-connector-aws/pull/188#discussion_r2042250368
##########
flink-connector-aws/flink-connector-aws-kinesis-streams/src/main/java/org/apache/flink/connector/kinesis/source/reader/KinesisShardSplitReaderBase.java:
##########
@@ -50,10 +49,10 @@
/** Base implementation of the SplitReader for reading from
KinesisShardSplits. */
@Internal
public abstract class KinesisShardSplitReaderBase
- implements SplitReader<Record, KinesisShardSplit> {
+ implements SplitReader<KinesisClientRecord, KinesisShardSplit> {
Review Comment:
@Lzgpom Can you elaborate on what the user experience would be with the
current changes in PR? Will it break compilation for existing apps that already
depend on KinesisSource without further code changes?
##########
flink-connector-aws/flink-connector-aws-kinesis-streams/pom.xml:
##########
@@ -33,6 +33,14 @@ under the License.
<name>Flink : Connectors : AWS : Amazon Kinesis Data Streams Connector
v2</name>
<packaging>jar</packaging>
+ <repositories>
+ <!-- used for the kinesis aggregator dependency since it is not
available in maven central -->
+ <repository>
+ <id>jitpack.io</id>
+ <url>https://jitpack.io</url>
+ </repository>
Review Comment:
Would it be better to work with the owner of the repo to get this published
instead?
##########
flink-connector-aws/flink-connector-aws-kinesis-streams/src/main/java/org/apache/flink/connector/kinesis/source/serialization/KinesisDeserializationSchema.java:
##########
@@ -60,7 +60,7 @@ default void open(DeserializationSchema.InitializationContext
context) throws Ex
* @param output the identifier of the shard the record was sent to
* @throws IOException exception when deserializing record
*/
- void deserialize(Record record, String stream, String shardId,
Collector<T> output)
+ void deserialize(KinesisClientRecord record, String stream, String
shardId, Collector<T> output)
Review Comment:
+1
@Lzgpom Have we considered alternatives to changing the interface? I can see
that Hong suggested wrapping internally. Have we considered alternatives such
as having a separate KinesisClientRecordDeserializationSchema?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
