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
The above image creates the perception that at some point, we were supposed to create half-point events. Right now, our code specifies only an integer type, but we need it to be floating point. Or more precisely, a decimal.
We need it to be a decimal, as otherwise, we may run into floating point errors, such as the 0.2 + 0.1 problem. If you pop open any interpreter or language and add 0.2 and 0.1 together, you won't get 0.3, you'll get this:
>>> 0.2 + 0.1
0.30000000000000004
Decimal types, or arbitrary precision numeric values, allow us to specify how precise the number is after (and sometimes before) the decimal. So thus, we'll be able to store 0.5, 0.1, 1.0 and 3.5, but not 0.99, 1.565, or anything with more than 1 decimal point (if we want, which we do).
When we switch over (if this is agreed on), we'll need to make sure prior points and event point counts are preserved. Prisma's migration script may delete the previous column and set them all to zero, which we DON'T want.
Additionally, the UI around event creation needs to enable floating points, as well as limit the precision & scale as specified in the schema. Use the PostgreSQL reference below to learn about how it works.
The above image creates the perception that at some point, we were supposed to create half-point events. Right now, our code specifies only an integer type, but we need it to be floating point. Or more precisely, a decimal.
We need it to be a
decimal
, as otherwise, we may run into floating point errors, such as the0.2 + 0.1
problem. If you pop open any interpreter or language and add 0.2 and 0.1 together, you won't get 0.3, you'll get this:Decimal types, or arbitrary precision numeric values, allow us to specify how precise the number is after (and sometimes before) the decimal. So thus, we'll be able to store 0.5, 0.1, 1.0 and 3.5, but not 0.99, 1.565, or anything with more than 1 decimal point (if we want, which we do).
When we switch over (if this is agreed on), we'll need to make sure prior points and event point counts are preserved. Prisma's migration script may delete the previous column and set them all to zero, which we DON'T want.
Additionally, the UI around event creation needs to enable floating points, as well as limit the precision & scale as specified in the schema. Use the PostgreSQL reference below to learn about how it works.
Decimal
Prisma Schema ReferenceThe text was updated successfully, but these errors were encountered: