Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

ActiveRecord: attribute dirty tracking ignored during after_create #6899

Closed
pivotal-ghostchips opened this Issue · 7 comments

8 participants

@pivotal-ghostchips

If an attribute is updated during an after_create callback, the attribute is not marked as dirty.

We've forked Rails and added a failing test for this issue (pivotal-ghostchips@9b2725f). However, before writing a fix, we'd like to confirm this is truly a bug and not expected behavior.

For convenience, here's the production code / failing test:

class ModelWithAfterCreateCallbacks < ActiveRecord::Base
  self.table_name = 'developers'

  NAME = "foo"
  after_create :set_name

  private
  def set_name
    self.name = NAME
  end
end
  def test_after_create_callbacks_honor_dirty_tracking
    m = ModelWithAfterCreateCallbacks.create
    assert_equal m.valid?, true
    assert_equal ModelWithAfterCreateCallbacks::NAME, m.name
    assert_equal m.changed_attributes.has_key?("name"), true
  end

Surprisingly, m.changed? is false, and m.changed_attributes is empty, even though the name property has changed and not been persisted.

@mauricio

Attributes are only changed until before you save. Once it's saved all attributes are assumed to be the correct value, hence not dirty. If you change them again after saving, they will then be dirty again.

@jsl

If the attributes in the ActiveModel instance are such that something is going to be updated in the db the next time #save is called, it seems like a bug. I would expect the AR::B attribute to be dirty in this case.

@dmathieu
Collaborator

I agree with @jsl. This seems like a bug.

@acapilleri

I think if it's a bug should not have sense the call_back before_validation and after_validation

@senny
Owner

the ActiveRecord::AttributeMethods::Dirty module is wrapped around save and save!. Since save triggers create eventually, the after_create callback is wrapped by save and therefore the dirty attributes are reset after the callback ran. I'm not sure if it is a bug or supposed to work the way it does.

@rafaelfranca @steveklabnik do you have any insights?

@steveklabnik
Collaborator

These kinds of problems make my head hurt, to be honest.

@rafaelfranca

It is supposed to work this way. after_create callbacks run before after_save callbacks and the changes are reseted after the after_save callback to make possible to users use these changes values in the callbacks.

@batter batter referenced this issue in airblade/paper_trail
Closed

Meta data for storing array of columns changed #286

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.