Skip to content
This repository

reset_column_information not called after each migration #6939

Closed
lulalala opened this Issue · 4 comments

4 participants

lulalala Rafael Mendonça França Katrina Owen Piotr Sarnacki
lulalala

I have made a demo app (https://github.com/lulalala/migration-bug) to demonstrate the issue. The readme shows the step to prepare the database, and reproduce the error.

Basically I have a migration B which adds a new column, and a migration C to fill that column. It works okay if those B & C are to run in one go. However I have a migration A which basically does some lookup, and when running A, B and C together, migration C won't update column at all.

If I explicitly call Item.reset_column_information at the end of migration A, then the bug disappears. Therefore I suspect that reset_column_information is not called after each migration (which I think it should).

I am using Rails 3.2.6 and Ruby 1.9.3

Katrina Owen

I believe this is the expected behavior.

Using models in your migration is considered iffy, and as such I'd expect that you're expected to jump through a hoop or two in order to do so.

The Rails Guide has a section about using models in your migration:

http://guides.rubyonrails.org/migrations.html#using-models-in-your-migrations

The example they use has a single migration with both the structural change and the data change in the same migration, and they clearly expect the developer to call reset_column_information.

If I'm reading this correctly, then column information is read in when the connection to the database is established.

All the pending migrations are run using the same connection pool, and therefore column information would not be expected to be refreshed until the next time you connect (e.g. the next time you run rake db:migrate).

https://github.com/rails/rails/blob/master/activerecord/lib/active_record/migration.rb#L738

lulalala

I believe that when multiple migrations are run, it should behave the same if I run them separately or run them together.

And the API said

Sometimes you’ll want to add a column in a migration and populate it immediately after. In that case, you’ll need to make a call to Base#reset_column_information

I take the meaning of immediate as being "within the same migration". And in my case I am using the model before the migration, and in different migration files. Which is completely different to what the API specify users to use reset_column_information.

Piotr Sarnacki
Collaborator
drogus commented

@lulalala I would say that this is a documentation issue, not code issue, as @kytrinyx points out.

Technically, we could run reset_column_information after each migration, but I'm not sure if there aren't any implications.

@tenderlove @jonleighton do you think about that? Is it safe to change this behavior? Is it worth it?

Katrina Owen kytrinyx referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Katrina Owen kytrinyx referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Katrina Owen kytrinyx referenced this issue from a commit
Katrina Owen Expand caveat about models in migrations (rails guide)
This is an attempt to address issue #6939, where an earlier migration
added a column to the database, and a later migration uses a model and
references that column.

When both migrations were run together with `rake db:migrate` the column
information in memory still referenced the old table structure.

Running the migrations separately fixed this, as a new connection was
then established before referencing the model. Explicitly calling
`reset_column_information` is a more reliable workaround.
a1d2f69
Rafael Mendonça França
Owner

Closed by #7050

Rafael Mendonça França rafaelfranca closed this
Ken Collins metaskills referenced this issue in rails-sqlserver/activerecord-sqlserver-adapter
Merged

Fixes issue 237: "No such column" when renaming some columns in the migrations #246

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.