Reading floating points into a field stored as Integers

Rails
1

Hi, I’m trying to follow the “AWDR” example of storing certain types of
numbers (in my case, percentages not money) as integers in the
database. I understand from the Depot application how to format the
output to have 2 places (or n places for that matter) decimal.

Now, I"m wondering about the input. It’s more natural for people to
enter numbers as “11.23” if that’s what it means rather than 1123.
What’s the correct way to fix this? Should I read the numbers as
entered by the user and multiply by 100 and type cast to integer (ouch,
my C programming is showing)

Thanks,
mohit.

2

As of yesterday, the new beta version of AWDWR references the use of
BigDecimal in Edge Rails, and says don’t bother with integers. So,
if you’re just getting started, I would “rake rails:freeze:edge” and
not bother with integers.

        - dan

–
Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000

3

Yep, by using migrations, you’re trading some potential optimizations
available from one kind of database for the ability to trivially
switch between databases. I think worrying about those extra 10
digits is likely a case of premature optimization, given the price of
disk drives.

        - dan

–
Dan K. mailto:[email protected]
http://www.dankohn.com/ tel:+1-415-233-1000

4

Thanks Dan!

That reminds me! I need to update my PDF! I’m not sure if the new
version of AWDWR covers how BigDecimal can be used in migrations. My
first feeling was that portable migrations are rather scant on data
types :expressionless:

For example, there is only one integer type which maps to int(11) on
MySQL. I have 18 fields in my model that take a value between 1 and 5.
It seems a bit of a waste. But, I’m just going along for now - will
drop the tables, change the migrations and re-apply later when I am done
with the first quick prototype to see where I’m heading.

Cheers
Mohit.

5

I agree with you! I’ve made a note in my programming log that it can be
optimized and has been marked for a later point in the development :slight_smile:
though I have to admit that it does bother me a bit since I come from a
C and assembly language background in which 10 extra bytes x 18 fields =
180 extra bytes per record would be considered career-ending :slight_smile:

Cheers
Mohit.