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

[Decimal] Fix Encoding Problem #734

Merged
merged 5 commits into from
Jun 17, 2024
Merged

[Decimal] Fix Encoding Problem #734

merged 5 commits into from
Jun 17, 2024

Conversation

Tang8330
Copy link
Contributor

Our previous library was susceptible to precision loss when converting from a big.Float into a big.Int. Repro: https://go.dev/play/p/qg8NODRlxi5

@Tang8330 Tang8330 marked this pull request as ready for review June 17, 2024 19:54
@Tang8330 Tang8330 added the bug Something isn't working label Jun 17, 2024
@@ -9,15 +9,20 @@ import (

// EncodeDecimal is used to encode a string representation of a number to `org.apache.kafka.connect.data.Decimal`.
func EncodeDecimal(value string, scale int) ([]byte, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

We should probably make scale an int64.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Really? I think if we were to change it, it should be like uint16

Copy link
Contributor Author

Choose a reason for hiding this comment

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

PostgreSQL permits the scale in a numeric type declaration to be any value in the range -1000 to 1000. However, the SQL standard requires the scale to be in the range 0 to precision. Using scales outside that range may not be portable to other database systems.

Copy link
Contributor Author

@Tang8330 Tang8330 Jun 17, 2024

Choose a reason for hiding this comment

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

I think other databases would be similar. I can add a TODO here, if you think it's helpful

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, are you mentioning this because we then don't need to convert on L17?

big.NewInt(int64(scale))

Copy link
Contributor

Choose a reason for hiding this comment

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

I just think that when it comes to mathematical operations we should avoid int and always try to use an integer with an explicit amount of bits (int16, int32, int64, etc). I would be fine with int16 here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah sgtm

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'm gonna add a TODO since it'll require refactoring our decimal type too.

@Tang8330 Tang8330 merged commit 9f1c5e2 into master Jun 17, 2024
1 check passed
@Tang8330 Tang8330 deleted the fix-encoding branch June 17, 2024 20:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants