1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00

minor changes in migrations guide

This commit is contained in:
Vijay Dev 2011-04-26 23:18:55 +05:30
parent d4259d8932
commit b105dc441b

View file

@ -58,7 +58,7 @@ end
This migration adds a +receive_newsletter+ column to the +users+ table. We want it to default to +false+ for new users, but existing users are considered This migration adds a +receive_newsletter+ column to the +users+ table. We want it to default to +false+ for new users, but existing users are considered
to have already opted in, so we use the User model to set the flag to +true+ for existing users. to have already opted in, so we use the User model to set the flag to +true+ for existing users.
Also, you might also found a smart migration file, which was introduced in the latest version of Rails: Rails 3.1 makes migrations smarter by providing a new <tt>change</tt> 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.
<ruby> <ruby>
class CreateProducts < ActiveRecord::Migration class CreateProducts < ActiveRecord::Migration
@ -73,8 +73,6 @@ class CreateProducts < ActiveRecord::Migration
end end
</ruby> </ruby>
This smart migration file knows how to migrate your database and reverse it in case you needed. It's more preferrable way to write a constructive (i.e. add column or add table) migration file.
NOTE: Some "caveats":#using-models-in-your-migrations apply to using models in your migrations. NOTE: Some "caveats":#using-models-in-your-migrations apply to using models in your migrations.
h4. Migrations are Classes h4. Migrations are Classes
@ -200,8 +198,6 @@ class RemovePartNumberFromProducts < ActiveRecord::Migration
end end
</ruby> </ruby>
NOTE: The generated migration file for destructive migration will be created using the old-style migration with +up+ and +down+ method. This because Rails doesn't know the original data type defined when you added the column.
You are not limited to one magically generated column, for example You are not limited to one magically generated column, for example
<shell> <shell>
@ -221,6 +217,8 @@ end
As always, what has been generated for you is just a starting point. You can add or remove from it as you see fit. As always, what has been generated for you is just a starting point. You can add or remove from it as you see fit.
NOTE: The generated migration file for destructive migrations will still be old-style using the +up+ and +down+ methods. This is because Rails doesn't know the original data types defined when you made the original changes.
h3. Writing a Migration h3. Writing a Migration
Once you have created your migration using one of the generators it's time to get to work! Once you have created your migration using one of the generators it's time to get to work!
@ -342,14 +340,14 @@ For more details and examples of individual methods check the API documentation,
h4. Writing Your +change+ Method h4. Writing Your +change+ Method
The +change+ method of your migration reduce the need for you having to write both +up+ and +down+ method in some case that Rails knows how to revert it. Rails will revert the changes automatically when you rollback your change. Currently, +change+ method only support these migration definitions: The +change+ method removes the need to write both +up+ and +down+ methods in those cases that Rails know how to revert the changes automatically. Currently, the +change+ method supports only these migration definitions:
* +create_table+ * +create_table+
* +add_column+ * +add_column+
* +rename_column+ * +rename_column+
* +add_index+ * +add_index+
If you're going to use another methods, you'll have to write both +up+ and +down+ method normally. If you're going to use other methods, you'll have to write the +up+ and +down+ methods normally.
h4. Writing Your +down+ Method h4. Writing Your +down+ Method