SEZ9 commented on issue #12923: URL: https://github.com/apache/seatunnel/issues/12923#issuecomment-6622290837
Thanks @taozhiyi13 for tracing the shared `MySqlTypeConverter` paths. The inventory matches the concern I raised: the current `GEOMETRY -> BYTES` mapping is a working opaque-binary transport contract for MySQL-to-MySQL, TiDB, and the StarRocks JDBC-compatible dialect, and `ST_AsWKB` is not a drop-in replacement there because it drops the MySQL SRID prefix. Yes, deferring MySQL JDBC spatial support and limiting the first version to MySQL-CDC -> Zeta -> Elasticsearch/OpenSearch resolves the JDBC compatibility concern from my side. Keeping the default `MySqlTypeConverter` mapping, MySQL JDBC Source, MySQL JDBC Sink, and the TiDB/StarRocks paths unchanged, while treating the CDC path as a new capability, is a reasonable first scope. The strict full-cluster upgrade boundary still applies to CDC spatial jobs, as you noted. Please update the normative STIP body with the four items you listed (compatibility inventory and unchanged JDBC behavior, the MySQL-CDC-only source contract, the upgrade boundary and restore behavior, and the revised test plan and scope), and remove the earlier JDBC `BYTES -> GEOMETRY(GEOMETRY)` migration text and the `ST_AsWKB` wording in the compatibility section so the body has one consistent story. Then start the `[DISCUSS][STIP-42]` thread on [email protected], include the one-PR versus stacked-PRs question there, and link the thread here. The STIP remains **Under Review** until the dev@ thread reaches consensus; please hold the implementation PR until then. <!-- streview-comment:2270 --> -- 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]
