Changes to the Rails updated_at column don't appear in version changesets

[brightbytes]

If I update some Rails model attribute then Rails will perform the update I requested and also update the updated_at field for that model.

However, the PaperTrail version changeset for the change doesn't contain a hash key updated_at: [<pre_value>, <post_value>].

PaperTrail does correctly record both :created_at and :updated_at when a record is initially created. The bug only appears with subsequent attribute updates.

I'm using Rails 3.2.16 with Ruby 1.9.3p429.

And yes, I do know I can reconstruct the approximate updated_at from the created_at field on the Version. Still, it would be nice if the changeset record recorded the change.

[batter]

What database adapter are you using? PaperTrail retrieves the objects to insert into the object_changes column from the changes method provided by ActiveModel::Dirty. Could you try adding this onto your model:

before_update do
  puts "--- changes:"
  p changes
end

And see what gets printed out into the console when you go to update the record? If the updated_at field is not being displayed in that print out then this may be an issue with Rails 3.2.16 not including it on the changes hash.

[brightbytes]

I'm using Postgres on Heroku via version 0.17.0 of the pg gem.

And yes, the updated_at column is definitely not in changes.

My guess would be that Rails updates updated_at via a before_update callback, and consequently order cannot be guaranteed.

However, I notice that the updated_at attribute is available when consulting changes in the after_update ... so, maybe PaperTrail should use the changes object from an after_update callback?

That is, I added this to my user class:

before_update { dputs changes }
after_update { dputs changes }

... and get this as the printout:

[18] pry(main)> u.save
********************************************************************************
{"city"=>["foobar", "foobar dude"]}
********************************************************************************
   (0.7ms)  UPDATE "users" SET "city" = 'foobar dude', "updated_at" = '2014-01-25 01:01:19.180640' WHERE "users"."id" = 26
********************************************************************************
{"city"=>["foobar", "foobar dude"], "updated_at"=>[Fri, 24 Jan 2014 16:55:34 PST -08:00, Fri, 24 Jan 2014 17:01:19 PST -08:00]}
********************************************************************************

[batter]

Sounds like the issue is with Rails. In order for that attribute to get pulled into the changes, it must be available in the changes hash from ActiveModel::Dirty during before_update callbacks from Rails. If I run that same test with Rails 4.0.2 it puts out the updated_at column in the changes hash during a before_update column fine.

[brightbytes]

True.

It just seems a bit brittle to me to use #changes in .before_update rather
than .after_update, since some folks may update their model attributes in a
.before_update, and thus miss the boat.

OTOH, I personally would use .before_validation on: :update to update model
attributes.

Also, I can infer the updated_at value from Version#created_at, so we're
good here.

Thanks for your help!

On Mon, Jan 27, 2014 at 7:45 AM, Ben Atkins notifications@git.luolix.topwrote:

Sounds like the issue is with Rails. In order for that attribute to get
pulled into the changes, it must be available in the changes hash from
ActiveModel::Dirty during before_update callbacks from Rails. If I run
that same test with Rails 4.0.2 it puts out the updated_at column in the
changes hash during a before_update column fine.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/323#issuecomment-33378583
.

[batter]

v4.0.0 will now use after_ callbacks for all version generation, so that should address the issue you see here. Feel free to give v4.0.0.beta2 a whirl and that should fix your issue. (See #375 and #374 for more details)