I do not know what this behavior was guaranteed, Dirty uses after_create / after_update callbacks to track changes.

But touch does not execute after_create / after_update callbacks. Therefore, it seems like specifications that can not get changed attributes.
https://edgeapi.rubyonrails.org/classes/ActiveRecord/Persistence.html#method-i-touch

Was this working with the old version of Rails?

Hello Yaginuma-san, thank you for your response.

Was this working with the old version of Rails?

I think saved_changes was introduced in rails 5.1, which seems to have the same behavior as 5.2.

But, touch only updates timestamps, so it seems wrong to claim that other changes occurred.

1) Failure:
--- expected
+++ actual
@@ -1 +1 @@
-["updated_at"]
+["id", "created_at", "updated_at"]

For example, the id has not changed, so it seems wrong to claim that it has changed.

@sgrif what do you think?

Thank you for your comment.

Since saved_changes is not affected by touch, changes made at create remain as they are.
Therefore, if do reload before touch, the result will be empty.

diff --git a/33429.rb b/33429.rb
index 422bafd..753b54e 100644
--- a/33429.rb
+++ b/33429.rb
@@ -45,6 +45,7 @@ end
 class BugTest < Minitest::Test
   def test_saved_changes
     post = Post.create!
+    post.reload
     post.touch
     assert_equal %w[updated_at], $after_touch_saved_changes.keys

$ ruby 33429.rb
Finished in 0.009886s, 101.1511 runs/s, 101.1511 assertions/s.

  1) Failure:
BugTest#test_saved_changes [33429.rb:50]:
Expected: ["updated_at"]
  Actual: []

1 runs, 1 assertions, 1 failures, 0 errors, 0 skips 

(I also want to wait for the other maintainer's comment ;)

Since saved_changes is not affected by touch, changes made at create remain as they are.
Therefore, if do reload before touch, the result will be empty.

Oh! I did not realize the changes were coming from the create. Thank you, that is helpful.

Maybe we just need to mention in the documentation, something like:

     # Saves the record with the updated_at/on attributes set to the current time
     # or the time specified.
     # Please note that no validation is performed and only the +after_touch+,
-    # +after_commit+ and +after_rollback+ callbacks are executed.
+    # +after_commit+ and +after_rollback+ callbacks are executed. No dirty-tracking
+    # occurs, meaning that the `Dirty` methods, like `changed?`, `previous_changes`,
+    # and `changes` return the same values before and after `touch`.
     #

I guess that makes some sense...

But we still need some way to tell which attributes were changed by the touch.

Could we introduce another mutation tracker that gets reset before the touch and modified by the touch so that it can be inspected to determine what was changed by the touch ... Maybe add something like changes_from_touch to the complement saved_changes and friends? Then, just like you can use saved_changes within an after_save, you could use touched_changes (or whatever we'd name it) inside an after_touch.

Or, if that seems like overkill (though with the existing complexity surrounding touch already like NoTouching and TouchLater how could it be? 😉), should we at least pass a hash of changes to the after_touch callback(s)?

This issue has been automatically marked as stale because it has not been commented on for at least three months.
The resources of the Rails team are limited, and so we are asking for your help.
If you can still reproduce this error on the 5-2-stable branch or on master, please reply with all of the information you have about it in order to keep the issue open.
Thank you for all your contributions.

Not stale. Waiting for #34306 (improves docs) to be merged.

kamipo closed this in d1107f4 13 hours ago

Thanks!

Dear contributors,

Reading carefully this issue and the related Pull Requests, I am still a bit confused with the behavior of Dirty with touch when it is triggered by association belongs_to with touch: true option.

It looks like touching objects "manually" versus "in cascade through belongs_to association" does not result in the same behavior.

Given the following models:

class Project < ActiveRecord::Base
  has_many :documents

  after_touch :my_after_touch_callback

  def my_after_touch_callback
    puts "updated_at_before_last_save:#{updated_at_before_last_save}"
  end
end

class Document < ActiveRecord::Base
  belongs_to :project, touch: true
end

I can observe different behaviors with Dirty methods:

Project.last.touch
# updated_at_before_last_save:2019-11-24 12:58:24 UTC

Project.last.documents.last.touch
# updated_at_before_last_save:

Am I wrong somewhere with my investigation? Is that the expected behavior regarding this issue resolution?

I was not able to find documentation about that, please apologize if my question is kind of newbie :-)

Hi Jean-Michel.

It looks like touching objects "manually" versus "in cascade through belongs_to association" does not result in the same behavior.

Not sure if it's a bug, but I can reproduce this in rails latest (6.0.1) with a script

However, saved_changes seems to work ..

  def my_after_touch_callback
    puts saved_changes[:updated_at] #=> [nil, 2019-11-25 ...
  end

Perhaps saved_changes works and updated_at_before_last_save does not, because the later only works after a Project save, not after a Project create?

.. [I] apologize if my question is kind of newbie ..

I think this is quite a complicated question, actually 😄 très difficile

Thank you for your answer @jaredbeck :-)
Do you think that I should open an issue to describe the discrepancy?