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

estimated temperature (estimate_temp) of locality is of type Decimal #648

Open
ShootingStar91 opened this issue Jan 1, 2025 · 1 comment

Comments

@ShootingStar91
Copy link
Contributor

ShootingStar91 commented Jan 1, 2025

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:

  • 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.
@ShootingStar91
Copy link
Contributor Author

As the actual tasks for this issue, I would suggest:

  • Make a validator which checks the estimate_temp field is not 1000 or higher
  • Add a warning of the runtime type differences vs what the types/data.ts types are defined as into some relevant developer documentation file

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

1 participant