Failing test case for values not persisting after add_column

[jdelStrother]

Given a migration like

  puts Post.inspect
  add_column :posts, :body, :string
  Post.find_each do |p|
    p.body = 'foo'
    p.save!
  end

both the assignment to 'body' and the save will succeed, but the value isn't written into the database, and you're left with nil values for 'body'.

(Obviously the "puts Post.inspect" is artificial - in our case, I think a plugin is loading our models prematurely, and so ActiveRecord caches the pre-migration column information)

The attached (failing) test checks that the new column's value is persisted properly. Perhaps this could be achieved by implicitly calling reset_column_information after each schema change. However, I don't care too much about that behaviour - I'd be just as happy with getting NoMethodError on trying to assign to 'body'. We were caught out and lost some production data because the model update appeared to work fine, when it was actually just dropping the values assigned to it.

See #6679 for prior discussion.

[josevalim]

I think @jonleighton has some plans for not allowing .body to work. Calling reset_column_information would also be possible, since AR already tracks its descendants.

[parndt]

Is it generally advised to assign values in a migration? Given that there's an acceptable workaround of reset_column_information is this an issue that needs solving?

[senny]

I agree with @parndt. This is not necessarily an issue we need to solve. In general using your models in your migrations leads to problems of some sort. If you absolutely have to you can use the workaround.

@rafaelfranca @carlosantoniodasilva thoughts?

[rafaelfranca]

I agree. Actually I always advice to never change data in migrations