restored version uses old updated_at

[nicolasfranck]

when I do the following...

l = Library.first
l.version_at(DateTime.now - 1.day)
l.save
l.updated_at

...the value of "updated_at" is not the current time,
but the time of the old version. This is also reflected
in the sql output.

This indeed restores the record to its old state.
But then again, after every restore, papertrail
stores the restored version, with the current
timestamp in the versions table. Why then is this not applied to the
restored record?

I tried adding "updated_at" to the "skip" fields,
but that results in the field becoming "nil".

any idea?

[nicolasfranck]

I also tried adding this field to the "ignore" fields

[batter]

You didn't change any values on the record, which is why the updated it isn't getting timestamped. Are you saying that you desire for the value to be touched at the time you save the restored version? Hmm... it might make sense. But ActiveRecord only touches that datetime if a value gets modified...

[nicolasfranck]

Not necessarily. Consider this example (only one field "description")

class Report < ActiveRecord::Base
  has_paper_trail :ignore => [:created_at,:updated_at]
  validates :description,:presence => true,:length => { :minimum => 1 }  
end

in the rails console:

report = Report.create(:description => "a")
#store date of first version: "Wed, 16 Apr 2014 16:18:34 CEST +02:00"
old_date = report.updated_at
#wait few seconds and then change value of description
report.description = "b"
#second version is stored
report.save
#retrieve first version (sometimes "old_date + 1.second" is necessary)
report = report.version_at(old_date)
#show changes
report.changes
=> {"description"=>["b", "a"], "created_at"=>[Wed, 16 Apr 2014 16:18:05 CEST +02:00, Wed, 16 Apr 2014 16:18:05 CEST +02:00], "updated_at"=>[Wed, 16 Apr 2014 16:18:34 CEST +02:00, Wed, 16 Apr 2014 16:18:05 CEST +02:00]}
#save old version back to the database
report.save

   (0.4ms)  BEGIN
  SQL (1.1ms)  UPDATE "reports" SET "description" = $1, "created_at" = $2, "updated_at" = $3 WHERE "reports"."id" = 2945  [["description", "a"], ["created_at", Wed, 16 Apr 2014 16:18:05 CEST +02:00], ["updated_at", Wed, 16 Apr 2014 16:18:05 CEST +02:00]]
  SQL (0.9ms)  INSERT INTO "versions" ("created_at", "event", "item_id", "item_type", "object", "object_changes") VALUES ($1, $2, $3, $4, $5, $6) RETURNING "id"  [["created_at", Wed, 16 Apr 2014 16:19:55 CEST +02:00], ["event", "update"], ["item_id", 2945], ["item_type", "Report"], ["object", "---\nid: 2945\ndescription: b\ncreated_at: 2014-04-16 14:18:05.306988000 Z\nupdated_at: 2014-04-16 14:18:34.681799000 Z\ntype: a\n"], ["object_changes", "--- !ruby/hash:ActiveSupport::HashWithIndifferentAccess\ndescription:\n- b\n- a\n"]]
   (2.4ms)  COMMIT
 => true

#report.updated_at has the value of old_date!

Conclusion: although activerecord clearly detects changes to the record, the timestamps are set to the corresponding values of the restored record.

[batter]

Oh... hmm, I see... So perhaps update_at and updated_on should be skipped for assignment during the reify method? Seems like it would be appropriate, otherwise we are manually overriding the normal functionality, right?

[nicolasfranck]

Indeed:

report = Report.first
report.updated_at = DateTime.now - 2.day
(0.4ms)  BEGIN
  SQL (36.9ms)  UPDATE "reports" SET "updated_at" = $1 WHERE "reports"."id" = 2945  [["updated_at", Mon, 14 Apr 2014 16:47:05 CEST +02:00]]
   (2.6ms)  COMMIT
 => true

activerecord does not expect you to change "updated_at"

[batter]

Thanks for catching and reporting this. Should be fixed by eb36d1a