ryanmeowy commented on issue #10203: URL: https://github.com/apache/seatunnel/issues/10203#issuecomment-6083712044
Following up on the earlier discussion in this issue. @mzw111's declared slice — *discovering newly matching tables during startup or restore, via a default-disabled configuration option* — is still unimplemented after two months, and I don't see a linked PR. I'd like to take this issue forward, building on that same slice, if you're not actively working on it. **Proposed scope (Phase 1, default-off option):** 1. A new regex-based dynamic table-discovery option (default disabled), wired at the startup/restore capture point where `IncrementalSource.java` already computes `newTables = Sets.difference(capturedTables, checkpointCapturedTables)` — that diff-merge is idempotent across restore, so Phase 1 only needs the static configuration gate plus the matching knob. Table filtering itself goes through the existing Debezium `RelationalTableFilters` per-connector plumbing. 2. OceanBase factory inherits the same option rule from the MySQL factory, so it gets the behavior with no extra mechanism. 3. Vitess / SQLServer / Db2 are explicitly out of scope for this slice. **Test plan:** extend the existing table-name matching suites with (a) pattern-compile errors, (b) `STARTUP_MODE = INITIAL`/phantom-mode interplay (a newly matching table appears only after the job is running), (c) existing exact-table-name behavior unchanged, (d) restore path re-discovery. If this matches the direction you had in mind, would the option name and the default-off attach point work for you? Happy to adjust before I open a PR. -- 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]
