SEZ9 commented on issue #8259: URL: https://github.com/apache/seatunnel/issues/8259#issuecomment-5358318641
Thanks @goutamadwant for reproducing this on current `dev` with the pinned Debezium 1.9.8.Final — that matches the boundary described earlier in this thread: the MySQL grammar accepts `TRUNCATE TABLE`, but no table-level event survives, and the current resolver drops the database-level record because it only accepts `ALTER TABLE` changes. To answer your question directly: the preference is to model `TRUNCATE` as a **separate table-operation event**, not as an extension of the existing `SchemaChangeEvent` hierarchy. `TRUNCATE` is destructive rather than structural, and destructive semantics already live separately on the sink/catalog side (`Catalog.ActionType.TRUNCATE_TABLE` and the save-mode truncate path), so overloading the column/schema-change model would blur that boundary. I also agree a source-only parser change is not safe on its own. Before implementation, the next step is a design-track issue or STIP-level proposal that covers: 1. the new table-operation event contract, separate from `SchemaChangeEvent`; 2. the risk areas you raised: sink capability declaration before a source may forward the event, flush/ordering guarantees, and replay behavior when truncate is applied at the sink before checkpoint completion; 3. fallback behavior for engines and sinks without full schema-evolution support. Once that contract is agreed, your proposed split — API/runtime contract, MySQL source parsing, MySQL JDBC sink handling, and recovery E2E coverage — sounds like the right sequencing, and I'd be glad to review it in that order. If you're willing to write up the design proposal first, please link it back here so this issue keeps tracking the feature end to end. Until then, this stays open as a design-boundary issue rather than merging a connector-local workaround. <!-- streview-comment:384 --> -- 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]
