Validate absence of

rubyonrails-core
1

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 effect?

Thanks, Paul

2

Interesting! Can you explain some uses cases?

If it makes sense I think it could be added.

3

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?

4

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 something?

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 benefit.

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.

Cheers, -foca

5

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).

HTH,

Peter

6

Bot trapping with hidden fields that no human would complete?

7

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.”

end end

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 ?

8

I just worked this into rails and submitted a pull request: https://github.com/rails/rails/pull/7155