-
Notifications
You must be signed in to change notification settings - Fork 16
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
Switch financial information to be stored as integers #416
Comments
I think a large part of the python code already uses the Decimal type to handle amounts. |
We also store things in the database using the |
The frontend is kinda lax on the precision, though. But the backend validates that the user was presented with the correct price. |
At least, I think our db stores them as decimals. It's possible that our database doesn't have support for decimals, and sqlalchemy falls back to floats. |
Decimal works but can be a bit tricky too. The database should be in decimal if I understand the code correctly, but as you say it could also be that the engine doesn't support it. I think integers would be easier to deal with than Decimal. But if we should change depends on on what others think. I also need to read up a bit more about it. The downside with integers would be that it would set a minimum price per unit of 1 öre or such. We for instance have acrylic with 100g unit instead of 1g so that can work too for high volume with low cost per volume items. Might be other downsides too The downside with Decimal is has limitations which might not be obvious. Integers might be more clear with their limitations. At the same time most of the code likely doesn't need to deal with Decimals on that level |
I experimented some and the db is using floats for me |
I honestly think this might be just a waste of time. Do we have any indication that the float precision would be too small and make any calculations become inaccurate? |
It's not the precision itself that is the problem. The problem is that floats can not be represented exactly in binary form. See for instance https://www.laac.dev/blog/float-vs-decimal-python/ |
Sql says that the db is decimal
But in Python sqlachlemy says it is float or int
|
We currently use floating point numbers to store prices, transaction amounts etc. This can causes errors because of various floating point related drawbacks when it comes doing math with them. I suggest we switch to using only integers with cent/ören. I don't think we have any bugs caused by this atm but for reliability we should probably fix it in the future.
I think we could convert the existing info by multiplying it with 100 and rounding off any extra digits. In theory there shouldn't be any extra digits.
The text was updated successfully, but these errors were encountered: