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

rubyonrails-talk
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

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 Stimon 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

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

6

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

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

Grar