'to_f or not to_f', that is the matter of my question

Rails
1

What is the best practice for handling ActiveRecord attributes in
logic when those attributes were allowed to be nil? I’ve been handling
the possibly-nil status of my Numeric attributes in my logic by
calling to_f (to_i) on them, but I wonder if there’s a better
practice? For example, default values could be set in the migration or
validations could set blank fields to a default.

Any suggestions on the best practice in this case?

Thanks,

Grar

2

On 5 April 2010 17:57, Grary [email protected] wrote:

What is the best practice for handling ActiveRecord attributes in
logic when those attributes were allowed to be nil? I’ve been handling
the possibly-nil status of my Numeric attributes in my logic by
calling to_f (to_i) on them, but I wonder if there’s a better
practice? For example, default values could be set in the migration or
validations could set blank fields to a default.

Any suggestions on the best practice in this case?

If you are treating nil as effectively 0.0 rather than no value then I
think there is a good argument for setting a default value, and not
allowing null in the db.

If you need to distinguish nil as being ‘no value’ which is different
from 0.0 then you cannot use a default value.

Colin

3

Colin,

So, there is something I will regret either in terms of i) db
performance or ii) db maintenance by not using default float (int)
defaults where appropriate?

My view of the tradeoff was: 1) coding defaults to the attributes in a
migration vs. 2) calling to_f (to_i)on them in logic.

With no previous experience in the matter, I’ll adopt your proposal.

Thanks,

Grar

4

Grary S. wrote:

So, there is something I will regret either in terms of i) db
performance or ii) db maintenance by not using default float (int)
defaults where appropriate?

My view of the tradeoff was: 1) coding defaults to the attributes in a
migration vs. 2) calling to_f (to_i)on them in logic.

Personally, I see no “tradeoff” here.

This is a matter of business logic. You want the column to either (a)
always have a specified rational value or (b) allow the value to be
unspecified.

I believe that most would agree that setting constraints NOT NULL
DEFAULT 0.0 would be the most reliable method for implementing (a) in a
RDBMS.

But, whatever technique you use to disallow NULL values in the database
is a matter of business logic, regardless of any other considerations,
such as performance or convenience.

5

Having duly considered it, I withdraw my suggestion of a ‘tradeoff’.

I’m better off for your comments, so thanks all.

Grar

6

On 5 April 2010 19:48, Grary [email protected] wrote:

Colin,

So, there is something I will regret either in terms of i) db
performance or ii) db maintenance by not using default float (int)
defaults where appropriate?

My view of the tradeoff was: 1) coding defaults to the attributes in a
migration vs. 2) calling to_f (to_i)on them in logic.

Sorry I don’t understand what you are saying here about there being a
tradeoff.

Colin