Hi Evan,
1. I'd recommend supporting DeserializationSchema in any case similar to
KafkaRecordDeserializationSchema.
First, it aligns with other sources and user expectations.
Second, it's a tad faster and the plan looks easier if you omit a chained
task.
Third, you can avoid quite a bit of boilerp
Hello again,
Thank you for all of your help so far, I have a few more questions if you
have the time :)
1. Deserialization Schema
There's been some debate within my team about whether we should offer a
DeserializationSchema and SerializationSchema in our source and sink.
If we include don't inc
Hi Evan,
A few replies / questions inline. Somewhat relatedly, I'm also wondering
> where this connector should live. I saw that there's already a pubsub
> connector in
> https://github.com/apache/flink/tree/bf40fa5b8cd5b3a8876f37ab4aa7bf06e8b9f666/flink-connectors/flink-connector-gcp-pubsub/src/m
Hi Arvid, thank you so much for the detailed reply!
A few replies / questions inline. Somewhat relatedly, I'm also wondering
where this connector should live. I saw that there's already a pubsub
connector in
https://github.com/apache/flink/tree/bf40fa5b8cd5b3a8876f37ab4aa7bf06e8b9f666/flink-connec
Hi Evan,
1) You are absolutely correct that we would urge users to add new sources
as FLIP-27 and new sinks as FLIP-143. I can provide guidance in both cases.
For FLIP-27 sources, I'd recommend using KafkaSource [1] and FileSource [2]
as a starting point. Especially basing the reader implementatio
