Skip to content
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

Implement .floor, .ceil, .trunc for the in-memory Decimal column #10887

Merged
merged 11 commits into from
Aug 28, 2024

Conversation

GregoryTravis
Copy link
Contributor

@GregoryTravis GregoryTravis commented Aug 23, 2024

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

  • The documentation has been updated, if necessary.
  • Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
  • All code follows the
    Scala,
    Java,
    TypeScript,
    and
    Rust
    style guides. In case you are using a language not listed above, follow the Rust style guide.
  • Unit tests have been written where possible.

@GregoryTravis GregoryTravis marked this pull request as ready for review August 23, 2024 18:48
Comment on lines -957 to +965
apply_unary_operation self UnaryRoundOperation.CEIL_INSTANCE
case self.inferred_precise_value_type.is_decimal of
True ->
apply_unary_operation self UnaryDecimalRoundOperation.CEIL_INSTANCE
False ->
apply_unary_operation self UnaryRoundOperation.CEIL_INSTANCE
Copy link
Member

Choose a reason for hiding this comment

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

Is there any reason why we cannot merge UnaryDecimalRoundOperation with UnaryRoundOperation?

I thought the whole idea behind the (relatively new) UnaryXyzOperation architecture was to decouple operations from storages.

Copy link
Member

Choose a reason for hiding this comment

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

But maybe I misunderstood the UnaryXyzOperation approach. If you think that splitting them is better, then I think it is okay to keep this as-is.

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 think they should be merged, but I was trying to preserve the existing structure until I was clear about the new plan. I have another task #10904 that will require merging these two, so if it's okay I'll merge them in that PR (which will happen as soon as this and #10344 are done).

Copy link
Member

@radeusgd radeusgd left a comment

Choose a reason for hiding this comment

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

Looks good to me, as written I'm wondering how we should approach our unary operations (as we probably will be moving binary ops to similar architecture some time in the future).

IMO there should be a single UnaryRoundOperation. My motivation is - if we will migrate binary operations to this architecture, we'll prefer to have a single BinaryAddOperation that is capable of handling all kinds of parameter combinations (int64 + float, float + int32 etc. etc.) - if we had a separate class for each combination it would be unmanageable I think.

On the other hand, I do appreciate the 'decoupling' that keeping the separate unary implementations distinct. They are a slightly different case since they do not suffer from the combination of parameters problem.

What do you think?

@GregoryTravis GregoryTravis merged commit 1804f31 into develop Aug 28, 2024
36 checks passed
@GregoryTravis GregoryTravis deleted the wip/gmt/10644-decimal-floor branch August 28, 2024 18:27
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