[GH-3263] Deprecate ST_Force_2D and ST_Force3DZ alias function names - #3264
Open
james-willis wants to merge 1 commit into
Open
[GH-3263] Deprecate ST_Force_2D and ST_Force3DZ alias function names#3264james-willis wants to merge 1 commit into
james-willis wants to merge 1 commit into
Conversation
…names Deprecate the legacy alias names on the Spark surface without changing behavior, as suggested in the apache/sedona-db#1162 review: warn users toward the canonical names (ST_Force2D, ST_Force3D) instead of propagating alias-for-alias parity to other engines. - One-time-per-JVM runtime warning when the deprecated SQL name is used (new DeprecationWarning.warnOnce helper) — the only channel that reaches SQL users - @deprecated on the Scala DataFrame API methods - DeprecationWarning + docstring note in the Python API; internal GeoPandas force_2d use switched to the canonical ST_Force2D - Docs: deprecation admonitions on the alias pages, canonical pages no longer advertise the aliases, summary table rows updated
Member
|
@james-willis PostGIS parity is strongly preferred. I think one important goal we want to achieve in Sedona 2.0 is the PostGIS and GeoPandas parity. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Did you read the Contributor Guide?
Is this PR related to a ticket?
[GH-XXX] my subject. Closes Deprecate ST_Force_2D and ST_Force3DZ alias function names #3263What changes were proposed in this PR?
Deprecate the legacy alias function names
ST_Force_2D(canonical:ST_Force2D) andST_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.WARNlog when the deprecated expression is instantiated (newDeprecationWarning.warnOncehelper), since SQL users never see compile-time annotations.@deprecated("Use ST_Force2D/ST_Force3D instead", "2.0.0")on thest_functionsmethods.warnings.warn(..., DeprecationWarning)plus a.. deprecated::docstring note; the internal GeoPandasforce_2duse is switched to the canonicalST_Force2Dso it doesn't warn.Discussion point —
ST_Force3DZ: unlikeST_Force_2D(a pre-2.1 PostGIS name that PostGIS itself deprecated),ST_Force3DZis the canonical name in current PostGIS (ST_Force3Dis its alias there). Deprecating it trades PostGIS name-compatibility for a single canonical name in Sedona. Happy to drop theST_Force3DZhalf 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/commoncompiles with the changes; the existingST_Force_2D/ST_Force3DZtests infunctionTestScalaanddataFrameAPITestScalacontinue 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?