Skip to content

Conversation

@wangrunji0408
Copy link
Contributor

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

This PR adds date/time types support for both Java UDF and Python UDF.

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
  • My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
  • All checks passed in ./risedev check (or alias, ./risedev c)
  • My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

Documentation

  • My PR contains user-facing changes.
Click here for Documentation

Types of user-facing changes

Please keep the types that apply to your changes, and remove the others.

  • SQL commands, functions, and operators

Release note

Date, time, timestamp and interval type are now supported in UDF.

@github-actions github-actions bot added type/feature Type: New feature. user-facing-changes Contains changes that are visible to users labels Jun 19, 2023
Copy link
Collaborator

@xxchan xxchan left a comment

Choose a reason for hiding this comment

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

Just did a quick browse and have some questions:

  • The diff looks like changing the implementation (e.g., nano -> micro), instead of adding new types. Could you explain a bit what's the behavior before and how it's changed? (If it's rejected, where is the boundary?)
  • There are also some minor changes regarding Decimal. Could you explain what's changed? (Moving that into a separate PR is even more preferable)

Comment on lines -168 to +170
DataType::Decimal => Self::Decimal128(28, 0), // arrow precision can not be 0
DataType::Decimal => Self::Decimal128(38, 0), // arrow precision can not be 0
Copy link
Collaborator

Choose a reason for hiding this comment

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

What does this change mean?

Copy link
Contributor Author

@wangrunji0408 wangrunji0408 Jun 20, 2023

Choose a reason for hiding this comment

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

Decimal128 has a max precision of 38 digits, but RisingWave only supports 28 digits due to its dependency on rust-decimal. Given that we have a plan to support 38 digits in the near future, it seems better to define the parameterless DECIMAL as 38 digits in the UDF protocol.

/**
* Combination of Period and Duration.
*/
public class PeriodDuration extends org.apache.arrow.vector.PeriodDuration {
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you elaborate on the motivation of not using org.apache.arrow.vector.PeriodDuration directly? Maybe it can be part of the javadoc of this class.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wanted to re-export this class in our package so that users don't need to be aware of arrow. But it seems that Java doesn't support a way like in Rust.

@codecov
Copy link

codecov bot commented Jun 20, 2023

Codecov Report

Merging #10399 (0954732) into main (583334a) will increase coverage by 0.00%.
The diff coverage is 77.77%.

@@           Coverage Diff           @@
##             main   #10399   +/-   ##
=======================================
  Coverage   70.47%   70.47%           
=======================================
  Files        1261     1261           
  Lines      215173   215182    +9     
=======================================
+ Hits       151650   151657    +7     
- Misses      63523    63525    +2     
Flag Coverage Δ
rust 70.47% <77.77%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/common/src/array/arrow.rs 68.71% <76.92%> (+0.31%) ⬆️
src/common/src/array/proto_reader.rs 88.88% <100.00%> (ø)
src/common/src/types/datetime.rs 62.01% <100.00%> (ø)

... and 1 file with indirect coverage changes

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@wangrunji0408
Copy link
Contributor Author

The diff looks like changing the implementation (e.g., nano -> micro), instead of adding new types. Could you explain a bit what's the behavior before and how it's changed? (If it's rejected, where is the boundary?)

Previously the arrow date/time types were arbitrary chosen and were not tested. This PR simply fixes the implementation. We use microsecond as the unit because RisingWave only supports microsecond resolution.

@wangrunji0408 wangrunji0408 enabled auto-merge June 21, 2023 02:36
@wangrunji0408 wangrunji0408 added this pull request to the merge queue Jun 21, 2023
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Jun 21, 2023
@wangrunji0408 wangrunji0408 enabled auto-merge June 21, 2023 05:45
@wangrunji0408 wangrunji0408 added this pull request to the merge queue Jun 21, 2023
Merged via the queue into main with commit c8e488c Jun 21, 2023
@wangrunji0408 wangrunji0408 deleted the wrj/java-sdk branch June 21, 2023 06:47
@CharlieSYH CharlieSYH added the 📖✓ Covered or will be covered in the user docs. label Jul 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

type/feature Type: New feature. user-facing-changes Contains changes that are visible to users 📖✓ Covered or will be covered in the user docs.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants