DanielLeens commented on issue #12923: URL: https://github.com/apache/seatunnel/issues/12923#issuecomment-6595078915
Thanks @taozhiyi13. Both decisions I asked for are now explicit, and I consider them settled for the STIP: 1. Generic MySQL JDBC `GEOMETRY` changing from `BYTES` to `GEOMETRY(GEOMETRY)` is declared incompatible, with `ST_AsWKB(column)` migration, bilingual `incompatible-changes.md` entries, and before/after schema tests. 2. Spatial jobs require a strict full-cluster upgrade; a mixed-version failure is documented as a deserialization failure rather than presented as plan-time rejection, with tests for non-coercion, full-cluster restore, and old-version restore failure. Before the `[DISCUSS]` thread, two items are still open: **STIP body not yet updated.** The issue body still has no upgrade-boundary section, and its "Compatibility, Deprecation, and Migration Plan" still says MySQL JDBC "can keep the previous binary result" via `ST_AsWKB`. Please fold both decisions into the body so the dev@ thread points to one normative text. **The incompatible-change inventory is narrower than the code that consumes this mapping.** On current `dev`, `MySqlTypeConverter` maps `GEOMETRY` to `PrimitiveByteArrayType` (`MySqlTypeConverter.java:375-377`). This converter is shared beyond MySQL JDBC Source: `TiDBCatalog extends MySqlCatalog`, `StarRocksDialect extends MysqlDialect`, and the MySQL dialect is selected for every `jdbc:mysql:` URL. Also, `MysqlCreateTableSqlBuilder` (around line 195) reuses the source column type when auto-creating a MySQL sink table, so a MySQL-to-MySQL job with a generic `GEOMETRY` column currently carries that column as `BYTES`. Under this STIP, that job would carry `GEOMETRY` into a JDBC Sink that is explicitly out of scope. My reading, which still needs a test to confirm, is that `ST_AsWKB` is not a drop-in replacement there, because plain WKB has no MySQL SRID prefix. Please list the affected dialect, catalog, and sink combinations and state the expected result for each, especially MySQL-to -MySQL. Then the dev@ thread can decide on the break with its full scope visible. **Delivery.** PRs are squash-merged, so three commits in one PR will not stay separate in `dev` history. Please bring the one-PR versus stacked-PRs choice to the dev@ thread. Whichever you choose, each slice's tests need to be reviewable on their own. Next step: update the body, open `[DISCUSS][STIP-42]` on [email protected], and link the thread here. Once the thread reaches consensus, we can mark the STIP accepted and you can open the implementation work. Please do not open the implementation PR before then. -- 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]
