-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-31086][SQL] Add Back the Deprecated SQLContext methods #27839
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| /** | ||
| * @deprecated As of 1.3.0, replaced by `createDataFrame()`. | ||
| */ | ||
| @deprecated("Use createDataFrame instead.", "1.3.0") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree; I also don't feel strongly about it as there isn't much overhead to keeping it, beyond API noise.
@gatorsmile may have some additional info or data about this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The rubric says nothing about how old the deprecation warning is on purpose. It says we should think about usage.
@gatorsmile do you have any reason to believe these are commonly used functions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At least these Spark books are still using this API in their examples, although the first two claims they are updated using Spark 2.x
dongjoon-hyun
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, All (including reviewers).
Although this is marked as Draft clearly, I want to make it sure that we need to hold on this until we have a vote.
|
Yes, is it simpler to just list the things being proposed to change and why (i.e. any data or arguments to support it) first? It does seem like a whole lot is being added back, which is at odds with what I understand to be the conclusion of the last thread on this. |
|
Test build #119482 has finished for PR 27839 at commit
|
|
CC @dongjoon-hyun @marmbrus @rxin @srowen This PR is ready for review. |
|
Test build #120243 has finished for PR 27839 at commit
|
|
Test build #120233 has finished for PR 27839 at commit
|
srowen
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel strongly about this either way. I think these APIs are going to be here forever if kept here now, and I don't see evidence they are used, so, why were they even deprecated and replaced? Deprecation loses meaning. But, they impose almost no maintenance burden as aliases, so "who cares?" can cut either way.
|
Test build #4999 has finished for PR 27839 at commit
|
cloud-fan
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM as these are easy to maintain.
### What changes were proposed in this pull request? Based on the discussion in the mailing list [[Proposal] Modification to Spark's Semantic Versioning Policy](http://apache-spark-developers-list.1001551.n3.nabble.com/Proposal-Modification-to-Spark-s-Semantic-Versioning-Policy-td28938.html) , this PR is to add back the following APIs whose maintenance cost are relatively small. - SQLContext.applySchema - SQLContext.parquetFile - SQLContext.jsonFile - SQLContext.jsonRDD - SQLContext.load - SQLContext.jdbc ### Why are the changes needed? Avoid breaking the APIs that are commonly used. ### Does this PR introduce any user-facing change? Adding back the APIs that were removed in 3.0 branch does not introduce the user-facing changes, because Spark 3.0 has not been released. ### How was this patch tested? The existing tests. Closes #27839 from gatorsmile/addAPIBackV3. Lead-authored-by: gatorsmile <[email protected]> Co-authored-by: yi.wu <[email protected]> Signed-off-by: gatorsmile <[email protected]> (cherry picked from commit b7e4cc7) Signed-off-by: gatorsmile <[email protected]>
|
Thanks! Merged to master/3.0 |
### What changes were proposed in this pull request? Based on the discussion in the mailing list [[Proposal] Modification to Spark's Semantic Versioning Policy](http://apache-spark-developers-list.1001551.n3.nabble.com/Proposal-Modification-to-Spark-s-Semantic-Versioning-Policy-td28938.html) , this PR is to add back the following APIs whose maintenance cost are relatively small. - SQLContext.applySchema - SQLContext.parquetFile - SQLContext.jsonFile - SQLContext.jsonRDD - SQLContext.load - SQLContext.jdbc ### Why are the changes needed? Avoid breaking the APIs that are commonly used. ### Does this PR introduce any user-facing change? Adding back the APIs that were removed in 3.0 branch does not introduce the user-facing changes, because Spark 3.0 has not been released. ### How was this patch tested? The existing tests. Closes apache#27839 from gatorsmile/addAPIBackV3. Lead-authored-by: gatorsmile <[email protected]> Co-authored-by: yi.wu <[email protected]> Signed-off-by: gatorsmile <[email protected]>
What changes were proposed in this pull request?
Based on the discussion in the mailing list [Proposal] Modification to Spark's Semantic Versioning Policy , this PR is to add back the following APIs whose maintenance cost are relatively small.
Why are the changes needed?
Avoid breaking the APIs that are commonly used.
Does this PR introduce any user-facing change?
Adding back the APIs that were removed in 3.0 branch does not introduce the user-facing changes, because Spark 3.0 has not been released.
How was this patch tested?
The existing tests.