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

PreciseDecimal to JSON number ends up with long list of decimals #11

Open
willthrom opened this issue Nov 10, 2022 · 3 comments
Open

PreciseDecimal to JSON number ends up with long list of decimals #11

willthrom opened this issue Nov 10, 2022 · 3 comments

Comments

@willthrom
Copy link

It seems from JSON to the PreciseDecimal we get the proper value but when writing back to JSON.... lots of decimal are added.

Not sure this is a problem for this library though. It is like the JSONEncoder ends up from PreciseDecimal to FLOAT to JSON-Number

image

Screen Shot 2022-11-10 at 12 06 05

@davdroman
Copy link
Owner

davdroman commented Nov 10, 2022

Yes, I'm afraid this is unavoidable because of how JSONEncoder is implemented. I'm planning a major release bump that moves away from literal numbers altogether and instead encodes decimals as strings by default. Details here #10.

It's really down to Apple to fix Decimal and the JSONSerialization APIs, but I wouldn't hold my breath for much longer at this point I'm afraid.

@willthrom
Copy link
Author

It is surprising a back end produce a decimal point number and we cannot return back the same decimal value.

in this case backend is in golang, using the library Decimal, which JSONEncoder seems to do fine. Android seems to be able to parse properly this JSON from Decimal and the encode it back to send to the same backend.

But with Apple, reading breaks in some situations and although with your library now reading works most of the time (if not always), writing back to JSON Number creates those precision issues.

Here I can only see two possible options, or our back end do the truncate always (or rounding to the nearest), or we change FE<->BE to use strings instead, but that is a big change (besides network usage). I need to find some time to do some research because my initial finding have very almost none. (We are moving to from FE doing maths operations to MOVE everything to the BE, so no more desaligment between platforms)

@davdroman
Copy link
Owner

davdroman commented Nov 10, 2022

Here I can only see two possible options, or our back end do the truncate always (or rounding to the nearest), or we change FE<->BE to use strings instead, but that is a big change1

You're correct. Although truncating/rounding is definitely the riskier choice.

Footnotes

  1. PS: I totally understand your discontent. It truly is ridiculous having this gap in the language in 2022 when Android solved it years ago.

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

No branches or pull requests

2 participants