james-willis opened a new pull request, #3264:
URL: https://github.com/apache/sedona/pull/3264

   ## Did you read the Contributor Guide?
   
   - Yes, I have read the [Contributor 
Rules](https://sedona.apache.org/latest/community/rule/) and [Contributor 
Development Guide](https://sedona.apache.org/latest/community/develop/)
   
   ## Is this PR related to a ticket?
   
   - Yes, and the PR name follows the format `[GH-XXX] my subject`. Closes #3263
   
   ## What changes were proposed in this PR?
   
   Deprecate the legacy alias function names `ST_Force_2D` (canonical: 
`ST_Force2D`) and `ST_Force3DZ` (canonical: `ST_Force3D`) on the Spark surface, 
as suggested in the review of apache/sedona-db#1162: rather than propagating 
alias-for-alias parity to other engines, deprecate the aliases with a warning 
giving the canonical name. Behavior is unchanged — the aliases keep working.
   
   - **SQL users**: a one-time-per-JVM `WARN` log when the deprecated 
expression is instantiated (new `DeprecationWarning.warnOnce` helper), since 
SQL users never see compile-time annotations.
   - **Scala DataFrame API**: `@deprecated("Use ST_Force2D/ST_Force3D instead", 
"2.0.0")` on the `st_functions` methods.
   - **Python API**: `warnings.warn(..., DeprecationWarning)` plus a `.. 
deprecated::` docstring note; the internal GeoPandas `force_2d` use is switched 
to the canonical `ST_Force2D` so it doesn't warn.
   - **Docs**: the alias pages carry a deprecation warning admonition, the 
canonical pages no longer advertise the aliases, and the Geometry-Functions 
summary rows say "Deprecated alias of ...".
   
   **Discussion point — `ST_Force3DZ`:** unlike `ST_Force_2D` (a pre-2.1 
PostGIS name that PostGIS itself deprecated), `ST_Force3DZ` is the *canonical* 
name in current PostGIS (`ST_Force3D` is its alias there). Deprecating it 
trades PostGIS name-compatibility for a single canonical name in Sedona. Happy 
to drop the `ST_Force3DZ` half of this PR if PostGIS parity is preferred.
   
   Flink and Snowflake register the same alias names; if this direction is 
accepted, those surfaces can follow up separately.
   
   ## How was this patch tested?
   
   `spark/common` compiles with the changes; the existing 
`ST_Force_2D`/`ST_Force3DZ` tests in `functionTestScala` and 
`dataFrameAPITestScala` continue to exercise the aliases (behavior is 
unchanged; the runtime warning is log-only). Python modules pass syntax checks; 
the alias functions still dispatch to the same JVM functions.
   
   ## Did this PR include necessary documentation updates?
   
   - Yes, I have updated the documentation.
   


-- 
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]

Reply via email to