This is an automated email from the ASF dual-hosted git repository.
gengliangwang pushed a commit to branch branch-4.x
in repository https://gitbox.apache.org/repos/asf/spark.git
The following commit(s) were added to refs/heads/branch-4.x by this push:
new c1d2a3aaef7f [SPARK-55617][SQL][FOLLOWUP] Correct VariantGet `@since`
to 4.3.0 and expand its class doc
c1d2a3aaef7f is described below
commit c1d2a3aaef7f0b6313a341b6c3ba99dc87a0a208
Author: Gengliang Wang <[email protected]>
AuthorDate: Tue Jun 16 14:23:18 2026 -0700
[SPARK-55617][SQL][FOLLOWUP] Correct VariantGet `@since` to 4.3.0 and
expand its class doc
### What changes were proposed in this pull request?
Follow-up to #54394 (SPARK-55617). Two documentation-only changes to the
DSv2 connector expression `VariantGet`:
- Correct the `since` tag from `4.1.0` to `4.3.0`.
- Expand the class Javadoc (previously just "Variant get expression.") to
describe what the expression represents.
### Why are the changes needed?
This addresses a [review
comment](https://github.com/apache/spark/pull/54394#discussion_r3417960739) on
the original PR: `VariantGet` was marked `since 4.1.0`, which does not match
where the API actually ships. The change lands on master (5.0.0) and is
backported to branch-4.x, so the API first appears in 4.3.0; the `since` tag
should reflect that. The original one-line class doc also did not explain what
the expression is or how it maps to `variant_get` / `try_variant_get`.
> Note: `VariantExtraction` and `SupportsPushDownVariantExtractions` (added
under SPARK-54656) carry the same `since 4.1.0` and likely need an analogous
follow-up under that ticket. They are intentionally left out of this PR to keep
it scoped to SPARK-55617.
### Does this PR introduce _any_ user-facing change?
No behavior change. This only updates Javadoc and the `since` tag so the
published API documentation is accurate.
### How was this patch tested?
Documentation-only change (Javadoc and `since`); there is no code change,
so no tests were added. Verified the new comment lines stay within the Java
checkstyle line-length limit.
### Was this patch authored or co-authored using generative AI tooling?
Yes, generated with the assistance of Claude Code (Anthropic).
This pull request and its description were written by Isaac.
Closes #56537 from gengliangwang/SPARK-55617-followup.
Authored-by: Gengliang Wang <[email protected]>
Signed-off-by: Gengliang Wang <[email protected]>
(cherry picked from commit 8c6f26b602eb1b9f5c60ff6f2a61e0d824a7580a)
Signed-off-by: Gengliang Wang <[email protected]>
---
.../org/apache/spark/sql/connector/expressions/VariantGet.java | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git
a/sql/catalyst/src/main/java/org/apache/spark/sql/connector/expressions/VariantGet.java
b/sql/catalyst/src/main/java/org/apache/spark/sql/connector/expressions/VariantGet.java
index 35904fdf8228..b2eb71c89f7b 100644
---
a/sql/catalyst/src/main/java/org/apache/spark/sql/connector/expressions/VariantGet.java
+++
b/sql/catalyst/src/main/java/org/apache/spark/sql/connector/expressions/VariantGet.java
@@ -24,9 +24,14 @@ import
org.apache.spark.sql.internal.connector.ExpressionWithToString;
import org.apache.spark.sql.types.DataType;
/**
- * Variant get expression.
+ * A DSv2 connector expression that extracts a value from a variant column. It
reads the value at
+ * the JSON {@code path} from the variant {@code child} and casts it to {@code
targetType}. This is
+ * the connector-facing form of the {@code variant_get} / {@code
try_variant_get} SQL functions:
+ * {@link #failOnError()} selects between them (throw vs. return null on a
cast failure), and
+ * {@link #timeZoneId()} binds the time zone used for timestamp casts. {@code
V2ExpressionBuilder}
+ * produces it so data sources can push variant extractions down (for example
into filters).
*
- * @since 4.1.0
+ * @since 4.3.0
*/
@Evolving
public class VariantGet extends ExpressionWithToString {
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
