You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
But to confuse things more - the Decimal class apparently has toString and toJSON methods defined so that if you write console.log(estimate_temp) in backend, it will print a string of the value, instead of the object that it actually is. Of course you can verify that it is an object by doing console.log(typeof estimate_temp).
More importantly, once the data is JSON.stringify'd when sending it to frontend - it again just turns it into a string, so if the value is Decimal(5.123) it will just be a string of "5.123" in frontend.
Now at first I thought the writing of this value to db has to fail, because I hadn't taken any of this into account, but it seems it works (mostly) fine.
The mariadb column is more accurately Decimal(4, 1) which means that the number will have at most 4 digits total, and at most 1 digit after the dot. So for example 50.12 gets rounded into 50.1 in database.
However, a couple problems:
Numbers like 4000.1 will result in an error in the database, causing internal server error and a generic error for the user in frontend. Though, I don't know if anyone's going to try to write large numbers in that since it represents temperature, but still its good to know. As I said, "too" precise decimals will simply get rounded down and that's fine.
to fix this probably would be easiest to simply create a validator for the field that checks that the number isnt 1000 or higher
From developer POV, the typescript error is now maybe silenced but notice that the runtime type of that field is actually string in frontend. This may cause confusion, and usually you shouldn't have different types runtime than what you have in typescript. But this is a downside of how I tried to simplify handling all the fields in frontend (there may be more of similar cases, like numbers that are actually handled as strings due in the input fields). So for now I guess it's ok, but this should be kept in mind.
The text was updated successfully, but these errors were encountered:
In the mariadb, the now_loc table's column
estimate_temp
is Decimal: https://mariadb.com/kb/en/decimal/In schema.prisma I can see that prisma handles this field as Decimal ( https://www.prisma.io/docs/orm/prisma-client/special-fields-and-types ), which is from a library called Decimal.js https://mikemcl.github.io/decimal.js/
But to confuse things more - the Decimal class apparently has toString and toJSON methods defined so that if you write console.log(estimate_temp) in backend, it will print a string of the value, instead of the object that it actually is. Of course you can verify that it is an object by doing console.log(typeof estimate_temp).
More importantly, once the data is JSON.stringify'd when sending it to frontend - it again just turns it into a string, so if the value is Decimal(5.123) it will just be a string of "5.123" in frontend.
Now at first I thought the writing of this value to db has to fail, because I hadn't taken any of this into account, but it seems it works (mostly) fine.
The mariadb column is more accurately Decimal(4, 1) which means that the number will have at most 4 digits total, and at most 1 digit after the dot. So for example 50.12 gets rounded into 50.1 in database.
However, a couple problems:
The text was updated successfully, but these errors were encountered: