# 'to\_f or not to\_f', that is the matter of my question **URL:** \ **Category:** Rails\ **Created:** [April 5, 2010, 6:59pm UTC](https://www.ruby-forum.com/t/to-f-or-not-to-f-that-is-the-matter-of-my-question/186357 "2010-04-05T18:59:45Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![grar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/cc9497/32.png) [@grar](https://www.ruby-forum.com/u/grar)\ **Post date:** [April 5, 2010, 6:59pm UTC](https://www.ruby-forum.com/t/to-f-or-not-to-f-that-is-the-matter-of-my-question/186357/1 "2010-04-05T18:59:45Z")
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 ---
**Author:** ![grar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/cc9497/32.png) [@grar](https://www.ruby-forum.com/u/grar)\ **Post date:** [April 5, 2010, 7:37pm UTC](https://www.ruby-forum.com/t/to-f-or-not-to-f-that-is-the-matter-of-my-question/186357/2 "2010-04-05T19:37:48Z")
On 5 April 2010 17:57, Grary [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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 ---
**Author:** ![grar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/cc9497/32.png) [@grar](https://www.ruby-forum.com/u/grar)\ **Post date:** [April 5, 2010, 8:49pm UTC](https://www.ruby-forum.com/t/to-f-or-not-to-f-that-is-the-matter-of-my-question/186357/3 "2010-04-05T20:49:48Z")
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 ---
**Author:** ![grar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/cc9497/32.png) [@grar](https://www.ruby-forum.com/u/grar)\ **Post date:** [April 5, 2010, 9:29pm UTC](https://www.ruby-forum.com/t/to-f-or-not-to-f-that-is-the-matter-of-my-question/186357/4 "2010-04-05T21:29:41Z")
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. ---
**Author:** ![grar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/cc9497/32.png) [@grar](https://www.ruby-forum.com/u/grar)\ **Post date:** [April 6, 2010, 8:56pm UTC](https://www.ruby-forum.com/t/to-f-or-not-to-f-that-is-the-matter-of-my-question/186357/5 "2010-04-06T20:56:14Z")
Having duly considered it, I withdraw my suggestion of a ‘tradeoff’. I’m better off for your comments, so thanks all. Grar ---
**Author:** ![grar](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/g/cc9497/32.png) [@grar](https://www.ruby-forum.com/u/grar)\ **Post date:** [April 5, 2010, 9:41pm UTC](https://www.ruby-forum.com/t/to-f-or-not-to-f-that-is-the-matter-of-my-question/186357/6 "2010-04-05T21:41:18Z")
On 5 April 2010 19:48, Grary [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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