amount: create and return integer values #7
Conversation
Kunde21
force-pushed
the
5_int_bigint
branch
from
2274fe2
to
a35a9bd
Compare
|
Actually a bit surprised by how badly I borked that rebase. 😬 Fixed and squashed, so it's only the changes I intended to make. |
|
Thanks, that looks much better. Can we add some test coverage for the new methods? |
Kunde21
force-pushed
the
5_int_bigint
branch
2 times, most recently
from
92f09fb
to
b15b16b
Compare
| ctx.Rounding = extModes[mode] | ||
| ctx.Quantize(result, a.number, -int32(digits)) | ||
|
|
||
| return Amount{result, a.currencyCode} | ||
| } | ||
|
|
||
| func contextPrecision(digits ...int64) *apd.Context { |
There was a problem hiding this comment.
What is the reason behind introducing this logic? In which cases was the hardcoded 16 not enough?
There was a problem hiding this comment.
Testing with math.MaxInt64 failed, returning 0 from a call to Round()
Enable handling of 64-bit integer and big integer amount values in minor units. These types are seen in financial and banking APIs to avoid the possibility of invalid amounts when dealing with multiple currencies that have varying decimal handling.
Kunde21
force-pushed
the
5_int_bigint
branch
2 times, most recently
from
9e85b15
to
a39e001
Compare
In testing amounts at and near max int64, the hard-coded precision at 16 digits caused the amounts to be silently zeroed out. Predicting the correct precision isn't exact, and should be extended, but attempts to over-estimate the required precision to perform the calculation.
Kunde21
force-pushed
the
5_int_bigint
branch
from
a39e001
to
886e82d
Compare
amount.go
Outdated
| n := a.Round().number | ||
| n.Exponent = 0 |
There was a problem hiding this comment.
This may change the underlying number. I copied the value to avoid that.
There was a problem hiding this comment.
Whoops, that was unintentional. Reverted.
|
I finally have time to wrap this PR up. I'll continue pushing tweaks over the next day or two. |
|
Quick follow-up on this PR. Looking to migrate a few projects off of my fork, to clean things up a bit. |
|
Opened #11 for the other half, let's wrap it up there. |
Enable handling of 64-bit integer and big integer amount values in
minor units. These types are seen in financial and banking APIs to
avoid the possibility of invalid amounts when dealing with multiple
currencies that have varying decimal handling.
Related to #5 (implementation can be done separately with these changes in place)