DanielLeens commented on issue #12923: URL: https://github.com/apache/seatunnel/issues/12923#issuecomment-6290743374
Classification: D / API and Connector-V2 cross-connector spatial data contract. Thank you for converting #12832 into a concrete STIP. I rechecked current `dev`, the complete open-PR set, and recent merged work: SeaTunnel has MySQL spatial parser/type references and Elasticsearch/OpenSearch `geo_point`/`geo_shape` constants, but no API `GEOMETRY` SQL type or shared geometry carrier, and there is no competing implementation PR. The proposal correctly treats this as an end-to-end data contract rather than a sink-only mapping. This remains **STIP in review**; please do not open the implementation PR yet. Before endorsement, update the design with an explicit compatibility inventory for every persisted/transported schema representation (not only `CatalogTable`): the type encoding must be stable by name rather than ordinal, preserve existing column attributes, and have deterministic behavior when an older or unsupported component sees the new type. Also identify the exact Zeta serialization boundary and the Flink/Spark planning entry points, with tests proving rejection happens before source data is consumed. The source/sink contract should also state the authoritative handling for column-level SRID metadata when it is absent or stale relative to a row value, and make the existing-index/mapping validation failure messages part of the acceptance criteria. After those API, upgrade, and unsupported-engine boundaries are made testable, we can evaluate the proposal for acceptance and split implementation into reviewable, dependency-ordered work. -- 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]
