If you have a migration like this :
add_column :posts, :foo, :text
Post.find_each do |p|
p.foo = 'bar'
the posts are successfully saved, but the new value for 'foo' isn't persisted to the database - you just end up with a table full of nil values for 'foo'.
Post.reset_column_information fixes this. I was surprised, however, by the following -
I was unable to reproduce this. The test that I wrote is at https://gist.github.com/2906016
Have definitely encountered this on Postgres (but only in production mode, argh).
@waseem: I suspect there may be some caching happening on Person.all in your test.
We had it on mysql in 3.2.5. Let me see if I can come up with a test case...
Hmm. I don't know if it's been fixed in Rails 4, but this fails in 3.2.5 for me : https://gist.github.com/2907225
...yeah, I can't seem to reproduce in rails 4, but I've been digging through the source & can't quite figure out what's different.
Have you tried to git bisect ?
@waseem took me a while to spot, but this doesn't invoke the block :
person_klass.all do |person|
I suspect you meant
person_klass.find_each do |person|
I'm now able to reproduce it on 4.0 with this test : https://gist.github.com/2909025.
@jdelStrother Your test cases confirm that this is indeed an issue. I also looked at some test cases which call reset_column_information after add_column. I'm not sure if it's intended behavior though. Maybe you should submit a pull request addressing this issue. We can then gather core's attention then.
#6702 was closed because using Models in migrations is not advised at all. If you absolutely have to, there is the reset_column_information workaround.