diff options
Diffstat (limited to 'guides/source/migrations.md')
| -rw-r--r-- | guides/source/migrations.md | 35 |
1 files changed, 33 insertions, 2 deletions
diff --git a/guides/source/migrations.md b/guides/source/migrations.md index 705b65ee8b..57db14f30c 100644 --- a/guides/source/migrations.md +++ b/guides/source/migrations.md @@ -85,7 +85,7 @@ existing users. ### Using the change method -Rails 3.1 makes migrations smarter by providing a new `change` method. +Rails 3.1 and up makes migrations smarter by providing a `change` method. This method is preferred for writing constructive migrations (adding columns or tables). The migration knows how to migrate your database and reverse it when the migration is rolled back without the need to write a separate `down` method. @@ -235,6 +235,8 @@ adding these columns will also be created. For example, running $ rails generate model Product name:string description:text ``` +TIP: All lines starting with a dollar sign `$` are intended to be run on the command line. + will create a migration that looks like this ```ruby @@ -544,7 +546,7 @@ support](#active-record-and-referential-integrity). If the helpers provided by Active Record aren't enough you can use the `execute` method to execute arbitrary SQL. -For more details and examples of individual methods, check the API documentation. +For more details and examples of individual methods, check the API documentation. In particular the documentation for [`ActiveRecord::ConnectionAdapters::SchemaStatements`](http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/SchemaStatements.html) (which provides the methods available in the `up` and `down` methods), @@ -700,6 +702,14 @@ will run the `up` method from the 20080906120000 migration. This task will first check whether the migration is already performed and will do nothing if Active Record believes that it has already been run. +### Running Migrations in Different Environments + +By default running `rake db:migrate` will run in the `development` environment. To run migrations against another environment you can specify it using the `RAILS_ENV` environment variable while running the command. For example to run migrations against the `test` environment you could run: + +```bash +$ rake db:migrate RAILS_ENV=test +``` + ### Changing the Output of Running Migrations By default migrations tell you exactly what they're doing and how long it took. @@ -879,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 ---------------------- |