Understanding Rails validation: what does allow_blank do?

Question

I\'m quite new to Rails and found a little snippet to validate presence and uniqueness step by step: first check presence, then check uniqueness.

validates :         


        

Answer 1

Too much explain just make simple things more complicated, let's just say:

# do not use this validates to check if the value is blank

Answer 2

from Rails annotation

# * <tt>:allow_nil</tt> - Skip validation if the attribute is +nil+.
# * <tt>:allow_blank</tt> - Skip validation if the attribute is blank.

so, it means when we use allow_blank on email, if the email is nil, only one error added to errors object, jump the uniqueness validates.

Answer 3

In your code, :presence => and :uniqueness => are validators, while :allow_blank => is a default option that gets passed to other validators.

So your code:

validates(
    :email,
    :presence => true,
    :allow_blank => true,
    :uniqueness => { :case_sensitive => false }
)

Is equivalent to this code:

validates(
    :email,
    :presence => { :allow_blank => true },
    :uniqueness => { :allow_blank => true, :case_sensitive => false }
)

However, the presence validator ignores the allow_blank option, so your code ends up being essentially this:

validates(
    :email,
    :presence => { }, # `{ }` is equivalent to `true`
    :uniqueness => { :allow_blank => true, :case_sensitive => false }
)

Having :allow_blank => true in :uniqueness means that when the email is blank, the uniqueness validation will not be run.

One effect of this is that you eliminate a DB query.

E.g., without the :allow_blank => true condition you would see this:

>> user = User.new(email: nil)
>> user.valid?
  User Exists (0.2ms) SELECT  1 AS one FROM "users" WHERE "users"."name" IS NULL LIMIT 1
=> false
>> user.errors.messages
=> {:email=>["can't be blank"]}

But with the :allow_blank => true option you won't see that User Exists DB query happen.

Another edge-case side effect happens when you have a record with a blank email address in your DB already. In that case if you don't have the :allow_blank => true option on the uniqueness validator, then you'll see two errors come back:

>> user = User.new(email: nil)
>> user.valid?
  User Exists (0.2ms) SELECT  1 AS one FROM "users" WHERE "users"."name" IS NULL LIMIT 1
=> false
>> user.errors.messages
=> {:email=>["has already been taken", "can't be blank"]}

But with the :allow_blank => true option you'll only see the "can't be blank" error (because the uniqueness validation won't run when the email is blank).

Answer 4

:allow_blank is an option that will "disable" several of the validators, but not the presence validator. The result of using these two together is that when the field is left blank, you will get the :blank error message (i.e., "can't be blank"), but not the other error messages.

Answer 5

What you've got is equivalent to this (wrapped for clarity):

validates :email, :presence => true, 
            :uniqueness => { :allow_blank => true, :case_sensitive => false }

That's a little silly though since if you're requiring presence, then that's going to "invalidate" the :allow_blank clause to :uniqueness.

It makes more sense when you switch to using other validators.. say... format and uniqueness, but you don't want any checks if it's blank. In this case, adding a "globally applied" :allow_blank makes more sense and DRY's up the code a little bit.

This...

validates :email, :format => {:allow_blank => true, ...}, 
                  :uniqueness => {:allow_blank => true, ...}

can be written like:

validates :email, :allow_blank => true, :format => {...}, :uniqueness => {...}

Answer 6

The following distinction can be useful to know:

presence: true                    # nil and empty string fail validation
presence: true, allow_blank: true # nil fails validation, empty string passes