Revert remove insignificant digits

[njason]

When I went to revert #46, TestDecimal_RoundCash started failing because the RoundCash function (#66) relies on a Decimal with insignificant digits removed. To get around this problem I made a new function to remove insignificant digits

[mwoss]

Currently, there is a bug in RoundCash method, mentioned in #89. We have to fix this issue before merging this PR.

[mwoss]

It looks good, ready to merge :3

[philippgille]

@njason @mwoss

Thanks for maintaining this library 💪 ! A quick question regarding this PR:

Is it correct that when using Decimal in a struct and encoding an object of that struct and later decoding it (for example during persistence and retrieval from a DB) and comparing the two objects in a test with something like require.Equal() (which uses reflection.DeepEqual() under the hood), that after this PR the objects are seen as unequal, whereas before they were seen as equal?

And the correct way to compare them would be to either use String() on both objects or RescalePair() first?

[mwoss]

Hi @philippgille. I apologize for the late response, I had a tough weekend.
The scenario you've described should not have happened. Are you using correct struct tags so values can be properly serialized/deserialized? Could you give us a small code snippet to reproduce this issue?

[philippgille]

For creating a snippet I had another look and the root cause seems to be that the initial decimal is created with Round(6), while the Postgres database column is decimal(x, 8). So after fetching the number from the DB and deserializing it, a decimal with 8 decimal places is created. But the last two digits are 00, because the original decimal just had 6 decimal places. Now before this PR these two trailing zeroes were removed and thus the reflect.DeepEqual() check yielded true, while after this PR the trailing zeroes are not removed and thus the check yields false.

So in the end I'd say this library behaves correctly and as expected (8 decimal places in the DB lead to 8 decimal places in the deserialized field). It's just a breaking or at least noteworthy change.

[mwoss]

@philippgille Yes, if those decimals differ by two last zeroes after a comma, they for sure, should not be equal. This was discussed in depth in #107.

[philippgille]

Does it make sense to add a note to the README or so, because the behavior was different for almost exactly 3 years, so I can imagine other people updating the package and wondering about failing unit tests as well :)

[mwoss]

I'm 100% agreeing with you. I'm adding this task to our backlog.
Thanks a lot :))

[daemonfire300]

I'm 100% agreeing with you. I'm adding this task to our backlog. Thanks a lot :))

I could not find the backlog issue so pardon me for reviving this zombie thread 😄

#277

[tzachshabtay]

We just got burned by this breaking change after upgrading the package.
We need to know the precision ignoring trailing zeroes (i.e what Exponent used to do), my current workaround is:

func getOldExponent(x decimal.Decimal) int32 {
	return decimal.RequireFromString(x.String()).Exponent()
}

Is there a better way? @mwoss (p.s thank you for this library).

[mwoss]

I deeply apologize for my late reply! I was not actively maintaining this library in the past year :<

---

@daemonfire300 - Sure I will take a look at your PR

@tzachshabtay - I apologize for that. We should've communicated this change more broadly or introduced it in the 2.x release. Right now library does not provide an easy way to calculate precision ignoring trailing zeroes. You can do it your way or count the trailing zeroes and substract it from Exponent:

func getPrecisionWithoutTrailingZeroes(d Decimal) int32 {
	coeff := d.Coefficient().String()
	trailingZeroes := len(coeff) - len(strings.TrimRight(coeff, "0"))
	return min(0, d.Exponent()+int32(trailingZeroes)) // for positive exponents decimal precision is always 0
}