SEZ9 commented on PR #11932: URL: https://github.com/apache/seatunnel/pull/11932#issuecomment-5611752592
Thanks @DanielLeens — that answers the intent question directly, and I'm aligned with it. On `Collector.restoreSchema`: agreed that keeping it Zeta-only is a deliberate scope boundary rather than an accidental gap. Your re-pull of `b6c96b97356d` matches what I see — a no-op default on the shared `Collector` interface, with `SeaTunnelSourceCollector` as the only override in the diff and no Flink/Spark translation-layer collector touched. Since those engines keep the pre-existing no-op behaviour, this isn't a regression, and it's consistent with how `markSchemaChangeBeforeCheckpoint()` / `collect(SchemaChangeEvent)` already behave outside Zeta. I'll keep that thread open with the "known Zeta-only limitation for now" qualification rather than resolving it, and I agree extending `restoreSchema` to the Flink/Spark collectors is a separate enhancement, not a blocker here. I'll open a follow-up issue so it's tracked and link it on this thread once filed. On the docs/upgrade note: not done yet on my side. I still need to verify the "Checkpoint restore compatibility" section against the diff at `b6c96b97356d` — specifically that it covers the schema now being persisted in `JdbcSinkState` and the non-exactly-once writer now emitting state. I'll use the pointers from your 2026-09-08 comment and resolve that thread once confirmed. Appreciate the correction on the earlier "ready to merge" note — that matches my understanding of where things stand. What's left before I'd consider this clear: 1. My re-check of the earlier `IncrementalSourceReader` / `JdbcSink` points against `b6c96b97356d` — the null-vs-empty `checkpointTables` guard, the deserializer/collector restore gating, the first-non-null `TableSchema` selection in `restoreWriter`, the primary-key lookup from the restored schema, and null-Xid states reaching `JdbcExactlyOnceSinkWriter` after an `exactly_once` flip. 2. The docs/upgrade verification above. 3. Filing the follow-up issue for Flink/Spark `restoreSchema`. I'll post results here as I close each one out, and would welcome another pass from you once they're resolved. <!-- streview-comment:930 --> -- 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]
