#5440 ActiveRecord::record_timestamps broken in RC2 (regression from RC1) - Ruby on Rails

Type	To find
responsible:me	tickets assigned to you
tagged:"@high"	tickets tagged @high
milestone:next	tickets in the upcoming milestone
state:invalid	tickets with the state invalid
created:"last week"	tickets created last week
sort:number, importance, updated	tickets sorted by #, importance or updated
Combine keywords for powerful searching.
Use advanced searching »

This project is archived and is in readonly mode.

#5440 ✓resolved

ActiveRecord::record_timestamps broken in RC2 (regression from RC1)

Reported by Wincent Colaiuta | August 24th, 2010 @ 01:32 PM | in 3.0.2

Just noticed that ActiveRecord::Base.record_timestamps = false no longer prevents timestamps from being updated. This is a regression in RC2; the issue was not present in RC1.

Demo using an "Article" mode in a rails console session:

>> a=Article.first
  Article Load (0.2ms)  SELECT `articles`.* FROM `articles` LIMIT 1
>> Article.record_timestamps
=> true
>> Article.record_timestamps = false
=> false
>> Article.record_timestamps
=> false
>> a.public = false
=> false
>> a.save
  SQL (0.2ms)  UPDATE `articles` SET `public` = 0, `updated_at` = '2010-08-24 12:25:58' WHERE (`articles`.`id` = 1)

Same bug occurs when setting the record_timestamps value on ActiveRecord::Base itself:

>> ActiveRecord::Base.record_timestamps 
=> true
>> ActiveRecord::Base.record_timestamps = false
=> false
>> a=Article.first
  Article Load (0.2ms)  SELECT `articles`.* FROM `articles` LIMIT 1
>> a.public=true
=> true
>> a.save
  SQL (0.2ms)  UPDATE `articles` SET `public` = 1, `updated_at` = '2010-08-24 12:27:11' WHERE (`articles`.`id` = 1)

Going to use git bisect to see if I can locate the bad commit. There are a couple of candidates I can see in the history that touch code in the record_timestamps path. Will post back once I've found the commit.

Comments and changes to this ticket

Wincent Colaiuta August 24th, 2010 @ 01:40 PM

Assigned user set to “José Valim”

Output from git bisect reveals that this commit is the culprit:

30ea923040ded944209c98383389b6c9aafe806a is the first bad commit
commit 30ea923040ded944209c98383389b6c9aafe806a
Author: José Valim <jose.valim@gmail.com>
Date:   Thu Aug 12 12:04:16 2010 -0300

    Make update_attribute behave as in Rails 2.3 and document the behavior intrinsic to its implementation.

:040000 040000 22165ee5875272a3e985c8fec168483b2c885a89 2ec79fa40b23c189cad633ae076204835fda4e83 M  activerecord

José Valim August 24th, 2010 @ 01:56 PM
- Milestone cleared.
- State changed from “new” to “open”
- Importance changed from “” to “High”
Could you please to attach a failing test case in ActiveRecord test suite? And I will fix it ASAP.
José Valim August 24th, 2010 @ 02:15 PM
The fix is simple:

http://github.com/rails/rails/commit/30ea923040ded944209c98383389b6...

We are missing a parenthesis there. Just waiting for the test case to fix it (feel free to include the fix in your patch as well!).
You flagged this item as spam.
Wincent Colaiuta August 24th, 2010 @ 02:22 PM
Here's a test case, but I can't actually run it yet because Bundler is giving me hell. Hopefully it's right. In the meantime I'll continue to fight with Bundler.
- 0001-add-test-case-for-activerecord-baserecord_timestamp.patch 1.2 KB
Repository August 24th, 2010 @ 02:47 PM
- State changed from “open” to “resolved”
(from [6ef60bd9ffff44187b3016d00923835a609293bf]) Ensure timestamps are not generated when explicitly set to false [#5440 state:resolved] http://github.com/rails/rails/commit/6ef60bd9ffff44187b3016d0092383...
Repository August 24th, 2010 @ 02:48 PM
(from [c857bd23c0ee6f0368a75fe608faed9bbdf1a415]) Ensure timestamps are not generated when explicitly set to false [#5440 state:resolved] http://github.com/rails/rails/commit/c857bd23c0ee6f0368a75fe608faed...
You flagged this item as spam.
Wincent Colaiuta August 24th, 2010 @ 02:53 PM
Thanks for the quick fix.
Jeremy Kemper October 15th, 2010 @ 11:02 PM
- Milestone set to “3.0.2”
[bulk edit]