Hi Arvinder, We're excited that you're already diving into the IoTDB 2.X Table Mode concepts and Flink’s Dynamic Table APIs.
To help you build an accurate timeline for your proposal, here are direct answers to your architectural questions: Schema Management: We recommend primarily relying on Flink DDL to define the schema mapping (this keeps things clean, consistent with Flink’s Table API philosophy, and easier for users). Optionally, you can also support dynamic schema inference by querying IoTDB’s catalog (tags and fields) as a nice-to-have enhancement. API Foundation: Please target the DynamicTableSource / DynamicTableSink interfaces directly and adopt the FLIP-27 Source API from the start. There is no need to build a low-level DataStream Source/Sink first and then wrap it—this approach will keep the implementation modern and fully aligned with current Flink best practices. CDC Requirements: The entire CDC functionality is not required for this project. There is no need to implement any changelog streams (Update/Delete) at all. An append-only (Insert-only) Scan Table Source is perfectly sufficient to meet the core MVP requirements. Full CDC support can be considered completely out of scope. These guidelines should give you a solid foundation for your proposal. If you have any follow-up questions or want to discuss the timeline / deliverables in more detail, feel free to reply or schedule a quick call. Looking forward to seeing your official GSoC proposal—we wish you the best of luck! Best regards, Haonan > On Mar 18, 2026, at 6:30 AM, Arvinder Singh <[email protected]> > wrote: > > Hi Haonan and the IoTDB Dev Team, > I am Arvinder, writing to express my strong interest in the GSoC 2026 > project: "Flink Connector for IoTDB 2.X Table Mode." > I have been actively contributing to the Apache ecosystem, and one of the > major open-source contributions I made revolves around connectors at Apache > SeaTunnel. My pull request is nearing completion, where I implemented an MQTT > sink connector, managing connection lifecycles, ensuring robust fault > tolerance, and building comprehensive e2e test suites for reliable data > streaming. > I have been reviewing the IoTDB 2.X Table Mode concepts and Flink's Dynamic > Table Source and Sink APIs. I think transitioning from a tree-based model to > a table-based one will make the system much more organized and > inter-operable. It natively allows Flink users to treat time-series data as > relational tables, leading to standard SQL capabilities for real-time > analytics. > > As I draft my official GSoC proposal, I wanted to ask a few architectural > questions to ensure my timeline is accurate: > > > Schema Management: Should the Flink connector rely strictly on Flink's DDL to > define the schema mapping, or should it actively query IoTDB's catalog to > infer table schemas (tags and fields) dynamically? > API Foundation: Flink is deprecating the older Source/Sink Function > interfaces in favor of the new FLIP-27 Source API. For the Table Mode > connector, should I build a low-level DataStream Source/Sink first and wrap > it in the Table API, or target the DynamicTableSource / Sink interfaces > directly? > CDC Requirements: For the IoTDB Table Source, does the initial scope require > supporting full changelog streams (Update / Delete), or is an append-only > (Insert) Scan Table Source sufficient for the MVP? > Thank you for your time > > Regards, > Arvinder > Github <https://github.com/assokhi>
