Migrations Guide: Add semicolon to sentences before code block [ci skip]

1 files changed, 14 insertions, 14 deletions

diff --git a/guides/source/migrations.md b/guides/source/migrations.md
index 0f5379059e..5166e61ec5 100644
--- a/guides/source/migrations.md
+++ b/guides/source/migrations.md
@@ -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