Rails core - Nov 2013 - validates :boolean_field, presence: true misconceptions

Last night a friend of mine started ranting about validates_presence_of
:boolean_field returning not valid when the boolean field is false.

I checked the rails issues and this seems to be a pretty common concern
about the naming of  ''presence'' .

Instead of changing the behaviour of the presence validator, I was
wondering if maybe the answer to avoid such misconceptions could be to
create a new validator called presence_of_boolean that abstracts the
sometimes called "hacky" validates_inclusion in: [true, false]

What do you guys think?

Sergio Campamá

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

This will cause more misconceptions yet.

validate_presence_of :something

Means to me

something.prensent?

And

false.present? # => false

So even we call presence_of_boolean we still using the word presence that
means that I should expect to Rails call present?

validates_inclusion is not “hacky” to me, it is exactly what you want,
check if your value is included in the [true, false] array.

Rafael Mendonça França
http://twitter.com/rafaelfranca
https://github.com/rafaelfranca


On Thu, Nov 14, 2013 at 11:14 AM, Sergio Campamá
<sergio@satelinx.com>wrote:
> Last night a friend of mine started ranting about validates_presence_of
> :boolean_field returning not valid when the boolean field is false.
>
> I checked the rails issues and this seems to be a pretty common concern
> about the naming of  ''presence'' .
>
> Instead of changing the behaviour of the presence validator, I was
> wondering if maybe the answer to avoid such misconceptions could be to
> create a new validator called presence_of_boolean that abstracts the
> sometimes called "hacky" validates_inclusion in: [true, false]
>
> What do you guys think?
>
> Sergio Campamá
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

I agree with Rafael.

Using "boolean" in the macro name is also a smell for me. In Ruby all
objects are booleans. Ruby has no Boolean class, there is no hierarchy for
booleans, the boolean space is flat (confirmed by matz here
https://www.ruby-forum.com/topic/4412411#1103364). Thus, while I know what
you mean, it is not consistent with the language to have "boolean" in
the
name and restrict the implementation to `true` and `false`.

And that is why validates_inclusion makes sense, because you want to check
the value is one of two very specific objects.

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Yes, I get what you mean Rafael.

I think the main misconception is that in the database sense, a value of
''false'' is indeed present, and the only way for that field to
be NOT
present would be for it to be NULL, again in the database.

Now, in the application context, it is commonly believed that a value of
false translates to not being present. So there is the confusion.

Reading up the source, I now understand better that validations work on the
application context (besides ActiveRecord validators), so it makes sense to
use the inclusion validator.

Thanks,


On Thu, Nov 14, 2013 at 10:34 AM, Rafael Mendonça França <
rafaelmfranca@gmail.com> wrote:
> This will cause more misconceptions yet.
>
> validate_presence_of :something
>
> Means to me
>
> something.prensent?
>
> And
>
> false.present? # => false
>
> So even we call presence_of_boolean we still using the word presence that
> means that I should expect to Rails call present?
>
> validates_inclusion is not “hacky” to me, it is exactly what you want,
> check if your value is included in the [true, false] array.
>
> Rafael Mendonça França
> http://twitter.com/rafaelfranca
> https://github.com/rafaelfranca
>
>
> On Thu, Nov 14, 2013 at 11:14 AM, Sergio Campamá
<sergio@satelinx.com>wrote:
>
>> Last night a friend of mine started ranting about validates_presence_of
>> :boolean_field returning not valid when the boolean field is false.
>>
>> I checked the rails issues and this seems to be a pretty common concern
>> about the naming of  ''presence'' .
>>
>> Instead of changing the behaviour of the presence validator, I was
>> wondering if maybe the answer to avoid such misconceptions could be to
>> create a new validator called presence_of_boolean that abstracts the
>> sometimes called "hacky" validates_inclusion in: [true,
false]
>>
>> What do you guys think?
>>
>> Sergio Campamá
>>
>>
>>  --
>> You received this message because you are subscribed to the Google
Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to rubyonrails-core+unsubscribe@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

Sergio,

When I was starting with Rails, I felt a similar dissonance about the
presence validator, but as you say, it''s important to think of
validations
in the context of Rails. After all, an empty string is not NULL in the
database but would also fail the presence validator. As Rafael said, the
only thing that matters is how the value responds to present? (or
technically blank?).

This is probably super obvious to you, but if somebody finds the inclusion
check hacky, an application developer could always add their own general
purpose validator to explicitly guard against nil instead of blank. For
example (not production tested):

app/validators/not_nil_validator.rb
class NotNilValidator < ActiveModel::EachValidator
  def validate_each(object, attribute, value)
    if value.nil?
      object.errors[attribute] << (options[:message] || "is
required") #or
I18N message
    end
  end
end

app/models/person.rb
class Person < ActiveRecord::Base
  validates :active, :tos_agreed, not_nil: true
  validates :is_admin, not_nil: { message: ''cannot be nil'' }
end

-Al


On Thu, Nov 14, 2013 at 9:10 AM, Sergio Campamá <sergio@satelinx.com>
wrote:
> Yes, I get what you mean Rafael.
>
> I think the main misconception is that in the database sense, a value of
> ''false'' is indeed present, and the only way for that
field to be NOT
> present would be for it to be NULL, again in the database.
>
> Now, in the application context, it is commonly believed that a value of
> false translates to not being present. So there is the confusion.
>
> Reading up the source, I now understand better that validations work on
> the application context (besides ActiveRecord validators), so it makes
> sense to use the inclusion validator.
>
> Thanks,
>
>
> On Thu, Nov 14, 2013 at 10:34 AM, Rafael Mendonça França <
> rafaelmfranca@gmail.com> wrote:
>
>> This will cause more misconceptions yet.
>>
>> validate_presence_of :something
>>
>> Means to me
>>
>> something.prensent?
>>
>> And
>>
>> false.present? # => false
>>
>> So even we call presence_of_boolean we still using the word presence
>> that means that I should expect to Rails call present?
>>
>> validates_inclusion is not “hacky” to me, it is exactly what you want,
>> check if your value is included in the [true, false] array.
>>
>> Rafael Mendonça França
>> http://twitter.com/rafaelfranca
>> https://github.com/rafaelfranca
>>
>>
>> On Thu, Nov 14, 2013 at 11:14 AM, Sergio Campamá
<sergio@satelinx.com>wrote:
>>
>>> Last night a friend of mine started ranting about
validates_presence_of
>>> :boolean_field returning not valid when the boolean field is false.
>>>
>>> I checked the rails issues and this seems to be a pretty common
concern
>>> about the naming of  ''presence'' .
>>>
>>> Instead of changing the behaviour of the presence validator, I was
>>> wondering if maybe the answer to avoid such misconceptions could be
to
>>> create a new validator called presence_of_boolean that abstracts
the
>>> sometimes called "hacky" validates_inclusion in: [true,
false]
>>>
>>> What do you guys think?
>>>
>>> Sergio Campamá
>>>
>>>
>>>  --
>>> You received this message because you are subscribed to the Google
>>> Groups "Ruby on Rails: Core" group.
>>> To unsubscribe from this group and stop receiving emails from it,
send
>>> an email to rubyonrails-core+unsubscribe@googlegroups.com.
>>> To post to this group, send email to
rubyonrails-core@googlegroups.com.
>>> Visit this group at
http://groups.google.com/group/rubyonrails-core.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>>  --
>> You received this message because you are subscribed to the Google
Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to rubyonrails-core+unsubscribe@googlegroups.com.
>> To post to this group, send email to rubyonrails-core@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

On Nov 14, 2013, at 8:14 AM, Sergio Campamá wrote:
> Last night a friend of mine started ranting about validates_presence_of
:boolean_field returning not valid when the boolean field is false.
> 
> I checked the rails issues and this seems to be a pretty common concern
about the naming of  ''presence'' .
> 
> Instead of changing the behaviour of the presence validator, I was
wondering if maybe the answer to avoid such misconceptions could be to create a
new validator called presence_of_boolean that abstracts the sometimes called
"hacky" validates_inclusion in: [true, false]
> 
> What do you guys think?
I think that if you''re putting boolean columns in your DB that
don''t default to either true or false you are doing it wrong. If you
really want "yes / no / didn''t answer" semantics, use a type
that represents that.

--Matt Jones

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.

It is a good point you touch there, Matt. Maybe the use of presence is not
recommended for boolean columns, and the recommended practice is to set a
default, thereby ensuring that there will be only trues and falses...


On Thu, Nov 14, 2013 at 1:57 PM, Matt Jones <al2o3cr@gmail.com> wrote:
>
> On Nov 14, 2013, at 8:14 AM, Sergio Campamá wrote:
>
> > Last night a friend of mine started ranting about
validates_presence_of
> :boolean_field returning not valid when the boolean field is false.
> >
> > I checked the rails issues and this seems to be a pretty common
concern
> about the naming of  ''presence'' .
> >
> > Instead of changing the behaviour of the presence validator, I was
> wondering if maybe the answer to avoid such misconceptions could be to
> create a new validator called presence_of_boolean that abstracts the
> sometimes called "hacky" validates_inclusion in: [true, false]
> >
> > What do you guys think?
>
> I think that if you''re putting boolean columns in your DB that
don''t
> default to either true or false you are doing it wrong. If you really want
> "yes / no / didn''t answer" semantics, use a type that
represents that.
>
> --Matt Jones
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscribe@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/groups/opt_out.
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-core+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/groups/opt_out.