Skip to content

IGNITE-29045 SQL Calcite: Support Java temporal types in UDF and UDTF parameters and results - #13569

Merged
tkalkirill merged 10 commits into
apache:masterfrom
tkalkirill:ignite-29045
Sep 25, 2026
Merged

tkalkirill merged 10 commits into
apache:masterfrom
tkalkirill:ignite-29045

Conversation

@tkalkirill

Copy link
Copy Markdown
Contributor

@zstan zstan left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks ! now looks good, i`m ok with it if viza will pass.

private static TimeZone timeZone(DataContext ctx) {
TimeZone tz = DataContext.Variable.TIME_ZONE.get(ctx);

return tz != null ? tz : TimeZone.getDefault();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like DataContext.Variable.TIME_ZONE.get(ctx) is never can be null, why do we need this new check?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Constant folding uses RexExecutorImpl(DataContexts.EMPTY), where TIME_ZONE is null. Without this fallback, temporal conversions throw an NPE and Calcite skips constant folding. I verified this with deterministic UDFs accepting and returning java.util.Date. The fallback uses the same JVM default as BaseDataContext.

/** */
private static long fromLocalTs(DataContext ctx, long ts) {
TimeZone tz = DataContext.Variable.TIME_ZONE.get(ctx);
if (ts < GREGORIAN_CUTOVER) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is more correct fix for https://issues.apache.org/jira/browse/IGNITE-23772 ticket. Maybe we should check tests from PR for this ticket and if all these tests pass, close IGNITE-23772 after your fix?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This fix addresses the incorrect conversion of historical dates, and the tests from PR #11822 pass. However, literals such as DATE '1582-10-05' still fail during parsing. After this fix is merged, we should address those remaining cases under IGNITE-23772.


/** */
@Test
public void testSerializableTableFunctionResult() {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is so special in serialiazable values? Why check with Object type is not enough?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Serializable exercises a different type-mapping path: Object.class becomes Ignite’s OtherType, while Serializable.class becomes Calcite’s ROW type. The test checks that a java.sql.Date value in such a column remains unchanged instead of being converted to an integer based on its runtime class. The Object test only covers the custom OtherType path.

@tkalkirill
tkalkirill merged commit 0a3288a into apache:master Sep 25, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants