validates :boolean_field, presence: true misconceptions

rubyonrails-core
1

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á

2

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.

3

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.

4

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,

5

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

6

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

7

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…