Deprecate the behavior of AR::Dirty inside of after_(create|update|save) callbacks #25337

Merged
merged 1 commit into from Nov 1, 2016

Projects

None yet

5 participants

@sgrif
Member
sgrif commented Jun 9, 2016

We pretty frequently get bug reports that "dirty is broken inside of after callbacks". Intuitively they are correct. You'd expect Model.after_save { puts changed? }; model.save to do the same thing as model.save; puts model.changed?, but it does not.

However, changing this goes much farther than just making the behavior more intuitive. There are a ton of places inside of AR that can be drastically simplified with this change. Specifically, autosave associations, timestamps, touch, counter cache, and just about anything else in AR that works with callbacks have code to try to avoid "double save" bugs which we will be able to flat out remove with this change.

We introduce two new sets of methods, both with names that are meant to be more explicit than dirty. The first set maintains the old behavior, and their names are meant to center that they are about changes that occurred during the save that just happened. They are equivalent to previous_changes when called outside of after callbacks, or once the deprecation cycle moves.

The second set is the new behavior. Their names imply that they are talking about changes from the database representation. The fact that this is what we really care about became clear when looking at BelongsTo.touch_record when tests were failing. I'm unsure that this set of methods should be in the public API. Outside of after callbacks, they are equivalent to the existing methods on dirty.

I am not married to any of the method names. Please bikeshed the shit out of them, I am open to alternatives.

Dirty itself is not deprecated, nor are the methods inside of it. They will only emit the warning when called inside of after callbacks. The scope of this breakage is pretty large, but the migration path is simple. Given how much this can improve our codebase, and considering that it makes our API more intuitive, I think it's worth doing.

Unresolved questions

Do we want the "new behavior" methods to be in the public API at all? They are straight aliases to the existing methods in dirty after 5.2/6.0. However, since we get these bug reports, someone probably does want the new behavior today.

Still left todo

I need to improve the commit messages, and move the deprecation warning up to the caller of mutation_tracker to include the exact method to call instead. The current implementation is also emitting deprecation warnings in places where the calls are valid. This will be fixed by moving the warning to the right place.

@sgrif
Member
sgrif commented Jun 9, 2016

/cc @matthewd @rafaelfranca This is not ready to merge, but the remaining changes I have to make are to commit messages and where the deprecation warning is emitted, which shouldn't affect the discussion around this change.

@olivierlacan olivierlacan commented on the diff Jun 9, 2016
...verecord/lib/active_record/attribute_methods/dirty.rb
+ def will_save_change_to_attribute?(attr_name, **options)
+ mutations_from_database.changed?(attr_name, **options)
+ end
+
+ # Alias for `attribute_change`
+ def attribute_change_to_be_saved(attr_name)
+ mutations_from_database.change_to_attribute(attr_name)
+ end
+
+ # Alias for `attribute_was`
+ def attribute_in_database(attr_name)
+ mutations_from_database.original_value(attr_name)
+ end
+
+ # Alias for `changed?`
+ def has_changes_to_save?
@olivierlacan
olivierlacan Jun 9, 2016 Contributor

Wouldn't changes_to_be_saved? be more coherent with attribute_change_to_be_saved?

@sgrif
sgrif Jun 13, 2016 Member

The goal was to make the difference between some of the methods more clear. Do you think that model.changes_to_be_saved? reads clearly enough? Compared to model.has_changes_to_save?

@olivierlacan olivierlacan commented on the diff Jun 9, 2016
...verecord/lib/active_record/attribute_methods/dirty.rb
+ def has_changes_to_save?
+ mutations_from_database.any_changes?
+ end
+
+ # Alias for `changes`
+ def changes_to_save
+ mutations_from_database.changes
+ end
+
+ # Alias for `changed`
+ def changed_attribute_names_to_save
+ changes_to_save.keys
+ end
+
+ # Alias for `changed_attributes`
+ def attributes_in_database
@olivierlacan
olivierlacan Jun 9, 2016 Contributor

persisted_attributes seems a bit more straightforward as a method name, no?

@sgrif
sgrif Jun 13, 2016 Member

I'm not happy with either one. Both names imply to me that they would return the opposite of changed (e.g. return an array of all of the attribute names which are not changed)

@olivierlacan olivierlacan commented on the diff Jun 9, 2016
...verecord/lib/active_record/attribute_methods/dirty.rb
+ # original value and the saved value.
+ #
+ # Behaves similarly to +attribute_change+. This method is useful in after
+ # callbacks, to see the change in an attribute that just occurred
+ #
+ # This method can be invoked as `saved_change_to_name` in instead of
+ # `saved_change_to_attribute("name")`
+ def saved_change_to_attribute(attr_name)
+ mutations_before_last_save.change_to_attribute(attr_name)
+ end
+
+ # Returns the original value of an attribute before the last save.
+ # Behaves similarly to +attribute_was+. This method is useful in after
+ # callbacks to get the original value of an attribute before the save that
+ # just occurred
+ def attribute_before_last_save(attr_name)
@olivierlacan
olivierlacan Jun 9, 2016 Contributor

Will this return the attribute before the last save or the attribute before the last change?

@sgrif
sgrif Jun 13, 2016 Member

Neither? It will return the value of the attribute in the database before the most recent save. This could definitely be more clear in the method name. Not sure how to express it without going full cocoa

@olivierlacan
Contributor
olivierlacan commented Jun 10, 2016 edited

I feel like I need to wrap my mind around the name changes in the public API outside of the code to fully focus on their semantics (I hope that's not weird and distracting from the PR convo). I hope this helps.

Legend:

  • => in the meaning column means there's a non-boolean return value
  • empty columns in Prior Name mean the method didn't exist before
  • * before a new method name means it's an alias to the prior method
Prior Name New Name Meaning
attribute_was(attr_name) *attribute_in_database(attr_name) current database value of attribute
attribute_change(attr_name) *attribute_change_to_be_saved => the changed value for attribute
attribute_changed?(attr_name) *will_save_change_to_attribute?(attr_name) was attribute modified since last save
attribute_before_last_save(attr_name) => attribute value from before last save
changed *changed_attribute_names_to_save => name of attributes with changed values since last save
changes *changes_to_save => the changes to be saved to DB
changed? *has_changes_to_save? are there any changes to be saved to the DB?
changed_attributes *attributes_in_database => Hash of attribute names & new unsaved values
changed? has_changes_to_save? record has unsaved changes
saved_changes? did last save change record attributes?
saved_changes => Hash of all changes in last save
saved_change_to_attribute?(attr_name) did attribute change when record last saved?
saved_change_to_attribute(attr_name) => array of original & saved value from last save

@sgrif Please feel free to edit the above to correct any incorrect meaning.

@nateberkopec
Contributor

Are those aliases intended to be public? Wasn't sure. If they are public, I agree, they were sort of hard to wrap my head around.

@sgrif sgrif closed this Nov 1, 2016
@sgrif sgrif reopened this Nov 1, 2016
@sgrif sgrif Deprecate the behavior of AR::Dirty inside of after_(create|update|sa…
…ve) callbacks

We pretty frequently get bug reports that "dirty is broken inside of
after callbacks". Intuitively they are correct. You'd expect
`Model.after_save { puts changed? }; model.save` to do the same thing as
`model.save; puts model.changed?`, but it does not.

However, changing this goes much farther than just making the behavior
more intuitive. There are a _ton_ of places inside of AR that can be
drastically simplified with this change. Specifically, autosave
associations, timestamps, touch, counter cache, and just about anything
else in AR that works with callbacks have code to try to avoid "double
save" bugs which we will be able to flat out remove with this change.

We introduce two new sets of methods, both with names that are meant to
be more explicit than dirty. The first set maintains the old behavior,
and their names are meant to center that they are about changes that
occurred during the save that just happened. They are equivalent to
`previous_changes` when called outside of after callbacks, or once the
deprecation cycle moves.

The second set is the new behavior. Their names imply that they are
talking about changes from the database representation. The fact that
this is what we really care about became clear when looking at
`BelongsTo.touch_record` when tests were failing. I'm unsure that this
set of methods should be in the public API. Outside of after callbacks,
they are equivalent to the existing methods on dirty.

Dirty itself is not deprecated, nor are the methods inside of it. They
will only emit the warning when called inside of after callbacks. The
scope of this breakage is pretty large, but the migration path is
simple. Given how much this can improve our codebase, and considering
that it makes our API more intuitive, I think it's worth doing.
16ae3db
@sgrif
Member
sgrif commented Nov 1, 2016

Going to move forward with this change. If anyone has suggested improvements to the names of the new methods, please open a PR.

@sgrif sgrif merged commit 29b3b5d into rails:master Nov 1, 2016

0 of 2 checks passed

codeclimate Code Climate is analyzing this code.
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
@sgrif sgrif deleted the sgrif:sg-changes-in-callbacks branch Nov 1, 2016
@sgrif sgrif added a commit that referenced this pull request Nov 1, 2016
@sgrif sgrif Allow `autosave: true` to be used with inverse of
With the changes in #25337, double save bugs are pretty much impossible,
so we can just lift this restriction with pretty much no change. There
were a handful of cases where we were relying on specific quirks in
tests that had to be updated. The change to has_one associations was due
to a particularly interesting test where an autosaved has_one
association was replaced with a new child, where the child failed to
save but the test wanted to check that the parent id persisted to `nil`.

I think this is almost certainly the wrong behavior, and I may change
that behavior later. But ultimately the root cause was because we never
remove the parent in memory when nullifying the child. This makes #23197
no longer needed, but it is what we'll do to fix some issues on 5.0

Close #23197
c7adc61
@jaredbeck jaredbeck referenced this pull request in airblade/paper_trail Nov 22, 2016
Merged

Constrain AR < 5.1 #892

@dhh
Member
dhh commented on 16ae3db Dec 14, 2016

If you have a before_action callback that uses changes/attribute_changed?, then it'll emit a warning if that's triggered twice in a transaction, like on double save. Here's a failing test:

  test "changed? in before callback thats run twice in a transaction should not be deprecated" do
    klass = Class.new(ActiveRecord::Base) do
      self.table_name = "people"
      @@save_counter = 0

      before_update do
        first_name_changed?
      end

      after_update do
        @@save_counter = @@save_counter + 1
        save if @@save_counter < 2
      end
    end

    assert_not_deprecated do
      person = klass.create!(first_name: "Sean")
      person.update! first_name: 'Blue!'
    end
  end
Member
dhh replied Dec 14, 2016

I guess this isn't a big deal if people are just encouraged to switch to the specific checks against changes pending save / changes that have been saved. But don't feel like we're currently doing the best job of guiding in that direction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment