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 :email, :presence => true, :allow_blank => true, :uniqueness => { :case_sensitive => false }
I'm a little bit confused about using presence => true
and allow_blank => true
together.
Without using allow_blank => true
both rules will be checked at the same time and not step by step.
Why does allow_blank => true
do this magic?
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
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 => {...}
: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 (ie, "can't be blank"), but not the other error messages.
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.
Eg, 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).
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.
太多的解释只是让简单的事情变得更复杂,我们只想说:
# do not use this validates to check if the value is blank
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.