If blank values are allowed, then no errors are given on invalid formats about validates_timeliness

[dkharrat]

FYI, I also got this issue with Rails 3.0.10 and validates_timliness 3.0.7. Is it a regression?

[bjorntrondsen]

I upgraded to Rails 3.1.3 and the issue seem to have gone away.
dkharrat, have you tested on 3.0.11 yet?

[markusproske]

I have the same issue on Rails 3.1.3. The validation only works, if allow_blank is not set. Example for not-working validation: "validates_datetime :freezedate, :allow_blank => true"

[mogox]

This looks like a similar issue to this #59.

[adzap]

The specs you added are not quite right. Unfortunately the invalid! and valid! methods have an implicit use of the Person test model. This is a basic test class which does not have a shim for the attribute value caching. If you are using ActiveRecord the raw value should be cached and you won't get a nil back in the validator even with some bogus value assigned.

Try uncommenting this line in the config to ensure that the AR shim is loaded

  config.extend_orms = [ :active_record ]

I will add specs in the vain of what you are trying to show to clarify the issue, and that they already pass.

[bjorntrondsen]

OK, so those specs didnt do any good.
I've downloaded the latest version from master and verified that those specs you added pass, but I still cant make it work in my own app with the extend_orm configuration. Maybe I'm missing something obvious, I dont know.
Explicitly including ValidatesTimeliness::AttributeMethods in my model works though, but that shouldnt be necessary, right?

Here's the exact code copy pasted from my app with tests run from the rails console

ValidatesTimeliness.setup do |config|
  config.extend_orms = [ :active_record ]
  config.use_plugin_parser = true
  config.parser.remove_us_formats
end

class Customer < ActiveRecord::Base
  validates_date(:contract_expires, :allow_blank => true)
end

ruby-1.9.2-p180 :001 > c = Customer.new
ruby-1.9.2-p180 :002 > c.contract_expires = "fail"
ruby-1.9.2-p180 :003 > c.valid?
 => true 

Then I make a change to the customer model

class Customer < ActiveRecord::Base
  include ValidatesTimeliness::AttributeMethods
  validates_date(:contract_expires, :allow_blank => true)
end

ruby-1.9.2-p180 :001 > c = Customer.new
ruby-1.9.2-p180 :002 > c.contract_expires = "fail"
ruby-1.9.2-p180 :003 > c.valid?
 => false

I've found a solution that's good enough for me. Maybe it will help someone else.

[adzap]

What other gems or plugins are you using? Wondering if there is some conflict

[bjorntrondsen]

You are correct, I removed every gem except rails, mysql and validates_timeliness, and the validations worked correctly.
The gem conflict is with a gem called 'rails_exception_handler'. You should probably have a serious talk with the guy who maintains it.

Just kidding, it is being developed and maintained by me.
The problem could be load order related. Simply making sure the validates_timeliness initializer runs before the initializer for rails_exception_handler solves the problem. The exception handler doesnt monkey patch anything active_record related. I dont have time to look further into it right now, but I'll do it later tonight.

[bjorntrondsen]

OK, I figured it out. It's the same issue as this ticket: #35

The problem is not with the gem, but the gems initializer. The initializer manipulates a controller to make the controller compatible with an authorization mechanism. This causes everything in the load path to be loaded, including the models. So the models gets loaded before validates_timeliness has a chance to extend AR::Base.
A simple way to reproduce this is to create an initializer called something like "01_test.rb" with nothing but "ApplicationController" in it.

Too bad you didnt name the project "aardvark_validations" or something like that :p

The only solution I can think of is to try and warn the user if the models have already been loaded

Module.constants.each do |constant_name|
  constant = eval(constant_name.to_s)
  if(!constant.nil? && constant.is_a?(Class) && constant.superclass == ActiveRecord::Base)
    warn("Warning: ActiveRecord models have been loaded before ValidatesTimeliness was initialized (etc..)")
    break
  end
end

It loops through all classes, and gives a warning if any of them is a subclass of AR:Base. Not the most elegant block of code I have ever seen, but I dont know any other way. If you put that in orm/active_record.rb with an informative message it could save somebody an hour or two of debugging.

[adzap]

I have pushed a change to the Railtie which moves the AR loading hook outside the initializer to avoid late inclusion of the shim. Can you try this against your issue please.

[bjorntrondsen]

No, the patch did not work for me. Even though active_record is being added to VT.extend_orms before any initializer is run, the actual file is being required by VT.setup as far as I can tell, and that method is triggered by the initializer. The initializer still have to run before any other initializer that triggers model loading. If I make railtie.rb require orm/active_record.rb, then it works though, BUT:

When I was testing I discovered another problem. This commit seem to break the :allow_nil function with the same effect as the load order issue. I dont think the new issue is load order related, as it also happens when I have nothing but Rails, mysql and VT in the gemfile. The solution for the original issue does not fix this.

[adzap]

Closing this as I think we established this is (bad) behaviour of another gem.

[bjorntrondsen]

Close it if you wish, but it was not related to bad behaviour in another gem, it was related to initializers and load order.
The issue will occur if an initializer that runs before the validates_timeliness initializer tries to access a model or a controller.
The workaround is to make sure the first initializer that runs belongs to validates_timeliness.