Validate absence of

Hello Core,

I often need to validate the absence of active record fields. That
validation being the direct opposite of validating the presence of a
field. Would the core team be willing to accept a patch to that

Thanks, Paul

Interesting! Can you explain some uses cases?

If it makes sense I think it could be added.

Two that spring to mind are:

validates :auth_code, :absence => true, :unless => :payment_complete?
validates :comments, :absence => true, :unless => published?

There may in some cases be some perceived repetition along the lines
of the code below. I'd be interested to hear people's thoughts on if
this is acceptable. Though there is repetition I'd feel the intention
of the code is clear.
  validates :auth_code, :presence => true, :if => :payment_complete?
  validates :auth_code, :absence => true, :unless
=> :payment_complete?

Two that spring to mind are:

validates :auth_code, :absence => true, :unless => :payment_complete?

If the auth_code is something that won't be set until you get a
response from your payment gateway, then why bother with this? If what
you want is to prevent users from updating this field when submitting
the payment form, use attr_protected.

validates :comments, :absence => true, :unless => published?

I'm guessing something that isn't published usually won't be surfaced
to users, so no one will be able to comment on it. So why validate

Adding a validation means adding code that runs each time you save
your object, so validations that are just there to look nice but don't
really help (because they will always be valid since there's no way
the user can break them) will only make your app slower for no real

I'm not saying there's no use case for this (I just can't think of
any), but these particular use cases don't warrant adding anything
into core, IMO.


validates :comments, :absence => true, :unless => published?

A particular problem I would expect with this one is that a post
that has already received comments while it was published cannot

easily be unpublished.

post.update_attributes(:published => false)

will then fail because of this validation (and does it makes sense
to delete all comments when setting it to unpublished?).

A possible validation could then be:

validates :comments, :absence => true, :if => never_published?

More fundamentally, maybe there is a confusion between:

  • “validations” as intended to validate the user enter correct values

    through the {AP|GU}I before processing/persisting this data input

  • “assertions” as intended to double check the internal state of
    the program (I would typically raise an “internal error” with

    explanation on the problem if such an assertion failed).



Bot trapping with hidden fields that no human would complete?

I believe that this one was a bad example…

I found myself implementing this a couple times in the last year:

validate :a_or_b

def a_or_b

if a? && b?
self.errors.add :a, “You can’t choose both options at the same time.”


One of the cases was extremely common:
Choose something:
[ ] Option 1
[ ] Option 2
[ ] Option 3
[ ] Other
Each option would be an option_id : integer, and Other would be other_option : string .

For that case :

validates :option_id, :absence => true, :if => :other_option?

validates :other_option, :absence => true, :if => :option_id?

Would fit perfectly! (Considering that at least one of them is obrigatory).

What do you think ?

I just worked this into rails and submitted a pull request: