DanielLeens commented on issue #11364: URL: https://github.com/apache/seatunnel/issues/11364#issuecomment-4956719535
Thanks for listing these details so concretely. I agree they matter, but I would separate the questions that belong in the STIP / first PR contract from the implementation details that can be reviewed in code. To keep STIP-30 reviewable, I think the current v1 should still stay narrow: 1. define the small API-facing surface that lands in `seatunnel-api`, including which fields are optional versus connector-native 2. define how snapshot, incremental, and restore progress are represented at the contract level, including what `back pressure` can and cannot mean in v1 3. treat high / low watermark fields as raw connector-reported details when available, not as a universal requirement for every CDC connector 4. keep durable storage or history (`IMap`, memory, or other long-term storage choices) out of v1; the first goal here is the runtime progress model and its first validation path For MySQL CDC specifics such as splitter / task classes, I agree they should be explained, but I would put that mapping in the implementation PR description or a short design note linked from the PR, rather than forcing the main STIP body to become class-by-class. PR #11395 is the right place to show: - which runtime signals map to which v1 fields - how restore changes the reported phase / progress - what happens under back pressure when progress cannot safely advance If it helps, a short table in the issue body or PR description that maps `v1 field -> source signal -> optional/required -> first MySQL implementation point` would probably answer most of these questions without making the STIP too broad. -- 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]
