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

Merge pull request #12387 from francisgo/patch-9

Migrations Guide: Add semicolon to sentences before code block [ci skip]
This commit is contained in:
Rafael Mendonça França 2013-09-28 17:23:37 -07:00
commit 4b89734e8e

View file

@ -184,7 +184,7 @@ class RemovePartNumberFromProducts < ActiveRecord::Migration
end
```
You are not limited to one magically generated column. For example
You are not limited to one magically generated column. For example:
```bash
$ rails generate migration AddDetailsToProducts part_number:string price:decimal
@ -227,7 +227,7 @@ or remove from it as you see fit by editing the
`db/migrate/YYYYMMDDHHMMSS_add_details_to_products.rb` file.
Also, the generator accepts column type as `references`(also available as
`belongs_to`). For instance
`belongs_to`). For instance:
```bash
$ rails generate migration AddUserRefToProducts user:references
@ -269,7 +269,7 @@ end
The model and scaffold generators will create migrations appropriate for adding
a new model. This migration will already contain instructions for creating the
relevant table. If you tell Rails what columns you want, then statements for
adding these columns will also be created. For example, running
adding these columns will also be created. For example, running:
```bash
$ rails generate model Product name:string description:text
@ -303,7 +303,7 @@ braces. You can use the following modifiers:
* `polymorphic` Adds a `type` column for `belongs_to` associations
* `null` Allows or disallows `NULL` values in the column.
For instance, running
For instance, running:
```bash
$ rails generate migration AddDetailsToProducts 'price:decimal{5,2}' supplier:references{polymorphic}
@ -345,7 +345,7 @@ By default, `create_table` will create a primary key called `id`. You can change
the name of the primary key with the `:primary_key` option (don't forget to
update the corresponding model) or, if you don't want a primary key at all, you
can pass the option `id: false`. If you need to pass database specific options
you can place an SQL fragment in the `:options` option. For example,
you can place an SQL fragment in the `:options` option. For example:
```ruby
create_table :products, options: "ENGINE=BLACKHOLE" do |t|
@ -359,7 +359,7 @@ will append `ENGINE=BLACKHOLE` to the SQL statement used to create the table
### Creating a Join Table
Migration method `create_join_table` creates a HABTM join table. A typical use
would be
would be:
```ruby
create_join_table :products, :categories
@ -378,7 +378,7 @@ will create the `product_id` and `category_id` with the `:null` option as
`true`.
You can pass the option `:table_name` when you want to customize the table
name. For example,
name. For example:
```ruby
create_join_table :products, :categories, table_name: :categorization
@ -400,7 +400,7 @@ end
A close cousin of `create_table` is `change_table`, used for changing existing
tables. It is used in a similar fashion to `create_table` but the object
yielded to the block knows more tricks. For example
yielded to the block knows more tricks. For example:
```ruby
change_table :products do |t|
@ -464,7 +464,7 @@ or write the `up` and `down` methods instead of using the `change` method.
Complex migrations may require processing that Active Record doesn't know how
to reverse. You can use `reversible` to specify what to do when running a
migration what else to do when reverting it. For example,
migration what else to do when reverting it. For example:
```ruby
class ExampleMigration < ActiveRecord::Migration
@ -648,7 +648,7 @@ will update your `db/schema.rb` file to match the structure of your database.
If you specify a target version, Active Record will run the required migrations
(change, up, down) until it has reached the specified version. The version
is the numerical prefix on the migration's filename. For example, to migrate
to version 20080906120000 run
to version 20080906120000 run:
```bash
$ rake db:migrate VERSION=20080906120000
@ -665,7 +665,7 @@ down to, but not including, 20080906120000.
A common task is to rollback the last migration. For example, if you made a
mistake in it and wish to correct it. Rather than tracking down the version
number associated with the previous migration you can run
number associated with the previous migration you can run:
```bash
$ rake db:rollback
@ -683,7 +683,7 @@ will revert the last 3 migrations.
The `db:migrate:redo` task is a shortcut for doing a rollback and then migrating
back up again. As with the `db:rollback` task, you can use the `STEP` parameter
if you need to go more than one version back, for example
if you need to go more than one version back, for example:
```bash
$ rake db:migrate:redo STEP=3
@ -713,7 +713,7 @@ contents of the current `schema.rb` file. If a migration can't be rolled back,
If you need to run a specific migration up or down, the `db:migrate:up` and
`db:migrate:down` tasks will do that. Just specify the appropriate version and
the corresponding migration will have its `change`, `up` or `down` method
invoked, for example,
invoked, for example:
```bash
$ rake db:migrate:up VERSION=20080906120000
@ -755,7 +755,7 @@ Several methods are provided in migrations that allow you to control all this:
| say | Takes a message argument and outputs it as is. A second boolean argument can be passed to specify whether to indent or not.
| say_with_time | Outputs text along with how long it took to run its block. If the block returns an integer it assumes it is the number of rows affected.
For example, this migration
For example, this migration:
```ruby
class CreateProducts < ActiveRecord::Migration