Skip to content

Loading…

Expand the caveat about models in migrations in the rails guide. #7050

Merged
merged 1 commit into from

4 participants

@kytrinyx

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.

@kytrinyx

I'm not sure if this documentation change is enough to address the issue in #6939. Do you think it would be helpful to be more explicit?

@dmathieu

This is not informative enough. It might make people think there is some latency for new database fields to be considered, when it's only a simple in memory cache.
You could also mention the use of reset_column_information.

@kytrinyx

Good point. Ok, I've tried to expand it at the bottom of the existing section. I initially went overboard with code examples, but I think that it's not important enough to warrant a huge section for itself, I just want to make the point that using models is iffy and can lead to subtle and complicated problems, and that this should be handled with care.

I'd be happy to tweak further if you have any good ideas.

@rafaelfranca
Ruby on Rails member
@vijaydev
Ruby on Rails member

I feel this is a bit too verbose, but I'm ok to merge. Please either rebase & squash the commits into one, Or make these changes in docrails. Thanks.

@kytrinyx kytrinyx 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
@kytrinyx

Thank you. I've rebased and squashed the commits.

@vijaydev vijaydev merged commit cd98c25 into rails:master
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Oct 10, 2012
  1. @kytrinyx

    Expand caveat about models in migrations (rails guide)

    kytrinyx committed
    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.
This page is out of date. Refresh to see the latest.
Showing with 21 additions and 0 deletions.
  1. +21 −0 guides/source/migrations.md
View
21 guides/source/migrations.md
@@ -889,6 +889,27 @@ class AddFuzzToProduct < ActiveRecord::Migration
end
```
+There are other ways in which the above example could have gone badly.
+
+For example, imagine that Alice creates a migration that selectively
+updates the +description+ field on certain products. She runs the
+migration, commits the code, and then begins working on the next feature,
+which is to add a new column +fuzz+ to the products table.
+
+She creates two migrations for this new feature, one which adds the new
+column, and a second which selectively updates the +fuzz+ column based on
+other product attributes.
+
+These migrations run just fine, but when Bob comes back from his vacation
+and calls `rake db:migrate` to run all the outstanding migrations, he gets a
+subtle bug: The descriptions have defaults, and the +fuzz+ column is present,
+but +fuzz+ is nil on all products.
+
+The solution is again to use +Product.reset_column_information+ before
+referencing the Product model in a migration, ensuring the Active Record's
+knowledge of the table structure is current before manipulating data in those
+records.
+
Schema Dumping and You
----------------------
Something went wrong with that request. Please try again.