validates_date seems to break form helper about validates_timeliness

[adzap]

If you don't validate the date does the text_field version work?

[rbhitchcock]

Yes. Removing the date validation results in the text_field being populated
with the existing value, if it exists.
On Sep 2, 2011 5:09 AM, "adzap" <
[email protected]>
wrote:

If you don't validate the date does the text_field version work?

Reply to this email directly or view it on GitHub:

#52 (comment)

[adzap]

A failing test for this would be great help.

[anathematic]

+1 for this issue, not really sure how to test this but I'll give it a stab in the next day or two.

[adzap]

I have had a play and have seen the bug. It seems to only occur when the config.extend_orms = [:active_record] is set. Commenting it works ok.

[adzap]

I've found the issue. It's to do with the before_type_cast implementation not returning the initial attribute value. Will work on a fix.

On 20/09/2011, at 9:12 AM, [email protected] wrote:

• 1 for this issue, not really sure how to test this but I'll give it a stab in the next day or two.

Reply to this email directly or view it on GitHub:
#52 (comment)

[adzap]

v3.0.7 should fix this.

[pkmiec]

I'm using Rails 3.1 and I don't see how this fix helps. Here is an example,

model.my_date = 'foo'
model.my_date                    # --> nil
model.my_date_before_type_cast   # --> also nil!

Looking at the code, it seems validates_timeliness defines my_date= and stores the original value in @timelines_cache. In validates_timeliness 3.0.6, this value was then returned by validates timeliness' version of _before_type_cast. In 3.0.7, Rails' version of _before_type_cast is used which doesn't know anything about @timeliness_cache ... so it obviously returns nil.

[adzap]

Are you saying you are seeing the behaviour of your example using the current version of the plugin with Rails 3.1.0?

[pkmiec]

Yes. I am updating an app to from Rails 3.0 to Rails 3.1 and using validates_timeliness 3.0.7.

The problem occurs with 3.0.6 as well which is puzzling because I thought 3.0.6 defined its own before_type_cast method. Perhaps I'm missing something with how before_type_cast works in Rails 3.1.

[adzap]

Are you using ActiveRecord?

The before_type_cast method is only defined by the plugin if the a true value is passed to define_timeliness_before_type_cast method. The AR shim checks the version and passes a false if AR version is 3.1.0 or above. Therefore default AR before_type_cast implementation should be being used.

[stephanvane]

This issue still seems to exist when enabling the parser_plugin in rails 3.1.3:

ValidatesTimeliness.setup do |config|
  config.use_plugin_parser = true
end

model.my_date = 'foo'
model.my_date                  # --> nil
model.my_date_before_type_cast # --> nil!

When I turn off the parser_plugin it works as expected:

model.my_date = 'foo'
model.my_date                  # --> nil
model.my_date_before_type_cast # --> "foo"

[adzap]

Ok, I see the problem. I will work on a fix.

[pkmiec]

Thanks!

[stephanvane]

Thanks, good luck

[adzap]

I've pushed a fix which is a bit messy but it should work. Can you verify please. No gem update yet.

[stephanvane]

Unfortunately it doesn't work here, the whole parser-plugin seems to be disabled now:

version 3.0.8:

model.my_date = 'foo'
=> "foo"
model.valid?
=> false
model.errors[:my_date]
=> ["is not a valid date"]
ValidatesTimeliness.use_plugin_parser
=> true

New version from github:

model.my_date = 'foo'
=> "foo"
model.valid?
=> false # other errors in the model
model.errors[:my_date]
=> []
ValidatesTimeliness.use_plugin_parser
=> true

[adzap]

This would be a symptom of the attribute value caching not working, rather than the parser. But nonetheless, it is a problem I will look into.

[adzap]

I've released a new gem version. Please verify if it fixes this issue.

[stephanvane]

Hi,
I'm afraid this still doesn't resolve the issue. I'm using rails 3.2.0 and validates_timeliness 3.0.9. The output is the same again.

model.my_date = 'foo'
=> "foo"
model.valid?
=> false # other errors in the model
model.errors[:my_date]
=> []
ValidatesTimeliness.use_plugin_parser
=> true

In my model i have the line:
validates_date :my_date, allow_blank: true

If I change line 7 of active_record.rb to true. Everything seems to work as expected

# In active_record.rb of validates_timeliness 3.0.9
def self.use_plugin_cache?
  true
end

model.my_date = 'foo'
=> "foo"
model.valid?
=> false
model.errors[:my_date]
=> ["is not a valid date"]
model.my_date
=> nil
model.my_date_before_type_cast
=> "foo"
ValidatesTimeliness.use_plugin_parser
=> true

I hope this helps with the issue. Good luck

[adzap]

Yes, it does thanks.

On 27/03/2012, at 8:08 PM, Stephan van [email protected] wrote:

Hi,
I'm afraid this still doesn't resolve the issue. I'm using rails 3.2.0 and validates_timeliness 3.0.9. The output is the same again.

model.my_date = 'foo'
=> "foo"
model.valid?
=> false # other errors in the model
model.errors[:my_date]
=> []
ValidatesTimeliness.use_plugin_parser
=> true

In my model i have the line:
validates_date :my_date, allow_blank: true

If I change line 7 of active_record.rb to true. Everything seems to work as expected

# In active_record.rb of validates_timeliness 3.0.9
def self.use_plugin_cache?
 true
end

model.my_date = 'foo'
=> "foo"
model.valid?
=> false
model.errors[:my_date]
=> ["is not a valid date"]
model.my_date
=> nil
model.my_date_before_type_cast
=> "foo"
ValidatesTimeliness.use_plugin_parser
=> true

I hope this helps with the issue. Good luck

---

Reply to this email directly or view it on GitHub:
#52 (comment)

[adzap]

I have pushed a new release to fix this. Please give it a try.

[stephanvane]

Hi,
The fix seems to work for dates, but there are still some problems with times.

# entering an invalid time works as expected
model.my_time = '12:66'
=> "12:66"
model.my_time
=> nil
model.valid?
=> false
model.errors[:my_time]
=> ["is not a valid time"]

# entering an other string; doesn't work properly
model.my_time = 'foo'
=> "foo"
model.my_time
=> 2000-01-01 00:00:00 UTC
model.valid? 
=> false # other errors in the model
model.errors[:my_time]
=> []

[adzap]

I found the issue for the invalid time being returned as a time object. It is an ActiveRecord bug in dummy_string_to_time. I will close this issue and open a new one, to see I can do a work around. Also will fix the bug in AR hopefully.