DanielLeens commented on PR #11206:
URL: https://github.com/apache/seatunnel/pull/11206#issuecomment-6166326971
Thanks @SEZ9. Here is what I verified in the code at
`9007896511517e4b874142cfe704102861bbc444`, including the places where your ask
is not fully met yet.
**Is the deserializer the only path for runtime names? Yes, in main code.**
- The only production construction of a runtime `CreateTableEvent` is
`SeaTunnelRowDebeziumDeserializeSchema.java:323`, fed from
`pendingCreateTables`, which is filled only in `handleTableChangeStruct`
(`:130-165`).
- That method obtains the `CatalogTable` only through
`tableChangeCatalogTableConverter`, and the MySQL wiring at
`MySqlIncrementalSource.java:296-301` uses
`MySqlCatalogTableUtils.toRuntimeCatalogTable`, which first runs
`validateRuntimeTableIdentifiers` on database, schema, table, every column and
every primary-key column against the `[A-Za-z0-9_$]*[A-Za-z_$][A-Za-z0-9_$]*`
pattern (digit-leading names such as `2024_orders` pass, all-numeric names
fail). An `IllegalArgumentException` is caught at `:146-152`, logged at WARN
and that table is skipped.
- Because the sink only ever receives the validated `CatalogTable`, the
generated SQL and the `${database_name}_${table_name}` template are built from
validated names. I did not add a second check where the SQL is built; the
guarantee rests on this single boundary. Tables restored from a checkpoint
(`pendingRestoreTables`, `:510-521`) were validated when first registered.
**Javadoc on the fail-fast contract: not done yet.** The fail-fast behavior
exists (`MultiTableSinkWriter.java:508-513` throws an `IOException` naming the
sink type and table path when the factory does not opt in), but the Javadoc of
`SupportMultiTableSinkWriter#supportsNewlyCreatedTable` and
`TableSinkFactory#supportsNewlyCreatedTable` only says "connectors must opt
in". They do not say that a runtime `CreateTableEvent` is never silently
dropped. That is a real gap and I will add it with the next code push.
**JDBC sink docs: partly done.** `docs/en|zh/connectors/sink/Jdbc.md`
mention `generate_sink_sql = true` and say runtime table creation is not
supported with JDBC exactly-once, but they do not spell out the literal
`exactly_once = false` setting. I will make that explicit in the same push.
F4 (target-scope pinning), F5 (writer-creation `IOException`
retry/idempotency) and F6 (old-format `MultiTableState` restore note and test)
are still open and will come with the same push; I am not claiming them
resolved. Local compilation and tests were not run for this reply, and CI on
the current head is the gate.
--
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]