[AURON #2501] Support datediff function natively - #2502
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
The native datediff implementation/conversion currently lacks session-timezone handling for timestamp inputs, which can yield incorrect results vs Spark in non-UTC timezones.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
This PR adds native execution support for Spark SQL datediff(endDate, startDate) by converting Spark DateDiff expressions into Auron extension functions and implementing Spark_DateDiff in the native DataFusion extension layer, along with regression/unit test coverage.
Changes:
- Convert Spark
DateDiffexpressions to theSpark_DateDiffextension function inNativeConverters. - Register
Spark_DateDiffin the native extension function factory and implement its Date32 signed-day difference logic with null propagation. - Add regression coverage in
AuronFunctionSuiteand Rust unit tests for coredatediffcases.
File summaries
| File | Description |
|---|---|
| spark-extension/src/main/scala/org/apache/spark/sql/auron/NativeConverters.scala | Adds conversion of Spark DateDiff to Spark_DateDiff extension function. |
| spark-extension-shims-spark/src/test/scala/org/apache/auron/AuronFunctionSuite.scala | Adds Spark-vs-native regression test for datediff. |
| native-engine/datafusion-ext-functions/src/spark_dates.rs | Implements spark_datediff and adds Rust unit test coverage. |
| native-engine/datafusion-ext-functions/src/lib.rs | Registers Spark_DateDiff in the extension-function dispatch table. |
Review details
- Files reviewed: 4/4 changed files
- Comments generated: 3
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| pub fn spark_datediff(args: &[ColumnarValue]) -> Result<ColumnarValue> { | ||
| let dates = ColumnarValue::values_to_arrays(args)?; | ||
| let end_date = cast(&dates[0], &DataType::Date32)?; | ||
| let start_date = cast(&dates[1], &DataType::Date32)?; | ||
| let end_date = end_date | ||
| .as_any() | ||
| .downcast_ref::<Date32Array>() | ||
| .expect("cast to Date32 must succeed"); | ||
| let start_date = start_date | ||
| .as_any() | ||
| .downcast_ref::<Date32Array>() | ||
| .expect("cast to Date32 must succeed"); | ||
| let result = Int32Array::from_iter(end_date.iter().zip(start_date.iter()).map( | ||
| |(end_date, start_date)| { | ||
| end_date | ||
| .zip(start_date) | ||
| .map(|(end_date, start_date)| end_date.wrapping_sub(start_date)) | ||
| }, | ||
| )); | ||
|
|
||
| Ok(ColumnarValue::Array(Arc::new(result))) | ||
| } |
| case e: DateDiff => | ||
| buildExtScalarFunction("Spark_DateDiff", e.children, e.dataType) |
| checkSparkAnswerAndOperator( | ||
| "select datediff(end_date, start_date), datediff(end_date, date'2024-01-01') from t1") | ||
| } |
slfan1989
left a comment
slfan1989
left a comment
There was a problem hiding this comment.
Thanks for adding native support for datediff. The implementation and existing coverage look good. Since Spark inserts a cast to DateType before evaluating DateDiff, I don't think the native function needs an additional timezone argument. It would still be useful to add a non-UTC timestamp or string coercion case as regression coverage, but this is non-blocking. LGTM.
|
@Sigma-Ma Thanks for the contribution! Merged into the master. |
Which issue does this PR close?
Closes #2501
Rationale for this change
Spark
DateDiffexpressions are not currently converted to native expressions, so queries usingdatediffremain on the fallback path.This change adds native execution while preserving Spark's argument order, signed day difference, and null behavior.
What changes are included in this PR?
DateDiffexpressions inNativeConvertersSpark_DateDiffextension functionAuronFunctionSuiteAre there any user-facing changes?
No. The SQL syntax and result semantics remain unchanged. Eligible
datediffexpressions can now execute natively.How was this patch tested?
Was this patch authored or co-authored using generative AI tooling?
Generated-by: OpenAI Codex (GPT-5)
ASF guidance: https://www.apache.org/legal/generative-tooling.html