DanielLeens commented on issue #8259: URL: https://github.com/apache/seatunnel/issues/8259#issuecomment-5341927950
Thanks for digging into this against current `dev`. I checked the current source before replying, and I agree this should not go in as a narrow MySQL-source-only parser fix. Today the schema-evolution path is centered on structural `SchemaChangeEvent` / `TableEvent` handling, while destructive table operations already exist separately on the sink/catalog side through `Catalog.ActionType.TRUNCATE_TABLE` and the save-mode truncate path. So `TRUNCATE TABLE` is a real table-level operation, but it is not modeled in the current source -> engine -> sink evolution contract. Because of that, I would not overload the existing `SchemaChangeEvent` hierarchy with a quick connector-local special case first. The next step should be a design-track issue or STIP-level proposal that answers: 1. whether `TRUNCATE` belongs in a separate table-operation event family vs a broader DDL event contract; 2. what sink capability declaration is required before a source can forward that event; 3. what ordering / flush / checkpoint semantics protect against `truncate applied, later rows replayed` failure modes; 4. how engines and sinks without full schema-evolution support should behave. My current preference is: treat `TRUNCATE` as a separate table-operation event, not as an ordinary column/schema change. Once that contract is written down, it makes sense to split the work into API/runtime/sink pieces. Until then, I would keep this open as a design-boundary issue rather than merge a connector-local workaround. -- 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]
