Rails - Apr 2010 - 'to_f or not to_f', that is the matter of my question...

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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 5 April 2010 17:57, Grary
<grary.stimon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

On Apr 5, 1:35 pm, Colin Law
<clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:
> On 5 April 2010 17:57, Grary
<grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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.
-- 
Posted via http://www.ruby-forum.com/.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 5 April 2010 19:48, Grary
<grary.stimon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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
>
> With no previous experience in the matter, I''ll adopt your
proposal.
>
> Thanks,
>
> Grar
>
> On Apr 5, 1:35 pm, Colin Law
<clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
>> On 5 April 2010 17:57, Grary
<grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
>
> --
> You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
> To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

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

Grar

On Apr 5, 3:38 pm, Colin Law
<clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
wrote:
> On 5 April 2010 19:48, Grary
<grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
>
>
>
> > With no previous experience in the matter, I''ll adopt your
proposal.
>
> > Thanks,
>
> >Grar
>
> > On Apr 5, 1:35 pm, Colin Law
<clan...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote:
> >> On 5 April 2010 17:57, Grary
<grary.sti...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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
>
> > --
> > You received this message because you are subscribed to the Google
Groups "Ruby on Rails: Talk" group.
> > To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> > For more options, visit this group
athttp://groups.google.com/group/rubyonrails-talk?hl=en.
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.