Merge branch 'master' into set_binds

* master: (2794 commits)
  doc, API example on how to use `Model#exists?` with multiple IDs. [ci skip]
  Restore DATABASE_URL even if it's nil in connection_handler test
  [ci skip] - error_messages_for has been deprecated since 2.3.8 - lets reduce any confusion for users
  Ensure Active Record connection consistency
  Revert "ask the fixture set for the sql statements"
  Check `respond_to` before delegation due to: https://github.com/ruby/ruby/commit/d781caaf313b8649948c107bba277e5ad7307314
  Adding Hash#compact and Hash#compact! methods
  MySQL version 4.1 was EOL on December 31, 2009 We should at least recommend modern versions of MySQL to users.
  clear cache on body close so that cache remains during rendering
  add a more restricted codepath for templates fixes #13390
  refactor generator tests to use block form of Tempfile
  Fix typo [ci skip]
  Move finish_template as the last public method in the generator
  Minor typos fix [ci skip]
  make `change_column_null` reversible. Closes #13576.
  create/drop test and development databases only if RAILS_ENV is nil
  Revert "Speedup String#to"
  typo fix in test name. [ci skip].
  `core_ext/string/access.rb` test what we are documenting.
  Fix typo in image_tag documentation
  ...

Conflicts:
	activerecord/lib/active_record/associations/join_dependency/join_association.rb
	activerecord/lib/active_record/relation/query_methods.rb

1 files changed, 56 insertions, 51 deletions

diff --git a/guides/source/migrations.md b/guides/source/migrations.md
index 550f8fdc3c..5d5c2724b1 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
@@ -297,15 +297,16 @@ You can append as many column name/type pairs as you want.
 You can also specify some options just after the field type between curly
 braces. You can use the following modifiers:
 
-* `limit`        Sets the maximum size of the `string/text/binary/integer` fields
-* `precision`    Defines the precision for the `decimal` fields
-* `scale`        Defines the scale for the `decimal` fields
-* `polymorphic`  Adds a `type` column for `belongs_to` associations
+* `limit`        Sets the maximum size of the `string/text/binary/integer` fields.
+* `precision`    Defines the precision for the `decimal` fields, representing the total number of digits in the number.
+* `scale`        Defines the scale for the `decimal` fields, representing the number of digits after the decimal point.
+* `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}
+$ rails generate migration AddDetailsToProducts 'price:decimal{5,2}' supplier:references{polymorphic}
 ```
 
 will produce a migration that looks like this
@@ -313,8 +314,8 @@ will produce a migration that looks like this
 ```ruby
 class AddDetailsToProducts < ActiveRecord::Migration
   def change
-    add_column :products, :price, precision: 5, scale: 2
-    add_reference :products, :user, polymorphic: true, index: true
+    add_column :products, :price, :decimal, precision: 5, scale: 2
+    add_reference :products, :supplier, polymorphic: true, index: true
   end
 end
 ```
@@ -344,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|
@@ -358,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
@@ -366,34 +367,32 @@ create_join_table :products, :categories
 
 which creates a `categories_products` table with two columns called
 `category_id` and `product_id`. These columns have the option `:null` set to
-`false` by default.
-
-You can pass the option `:table_name` with you want to customize the table
-name. For example,
+`false` by default. This can be overridden by specifying the `:column_options`
+option.
 
 ```ruby
-create_join_table :products, :categories, table_name: :categorization
+create_join_table :products, :categories, column_options: {null: true}
 ```
 
-will create a `categorization` table.
+will create the `product_id` and `category_id` with the `:null` option as
+`true`.
 
-By default, `create_join_table` will create two columns with no options, but
-you can specify these options using the `:column_options` option. For example,
+You can pass the option `:table_name` when you want to customize the table
+name. For example:
 
 ```ruby
-create_join_table :products, :categories, column_options: {null: true}
+create_join_table :products, :categories, table_name: :categorization
 ```
 
-will create the `product_id` and `category_id` with the `:null` option as
-`true`.
+will create a `categorization` table.
 
 `create_join_table` also accepts a block, which you can use to add indices
 (which are not created by default) or additional columns:
 
 ```ruby
 create_join_table :products, :categories do |t|
-  t.index :products
-  t.index :categories
+  t.index :product_id
+  t.index :category_id
 end
 ```
 
@@ -401,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|
@@ -421,7 +420,7 @@ If the helpers provided by Active Record aren't enough you can use the `execute`
 method to execute arbitrary SQL:
 
 ```ruby
-Products.connection.execute('UPDATE `products` SET `price`=`free` WHERE 1')
+Product.connection.execute('UPDATE `products` SET `price`=`free` WHERE 1')
 ```
 
 For more details and examples of individual methods, check the API documentation.
@@ -448,7 +447,7 @@ definitions:
 * `create_table`
 * `create_join_table`
 * `drop_table` (must supply a block)
-* `drop_join_table`  (must supply a block)
+* `drop_join_table` (must supply a block)
 * `remove_timestamps`
 * `rename_column`
 * `rename_index`
@@ -465,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
@@ -649,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
@@ -666,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
@@ -684,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
@@ -694,22 +693,27 @@ Neither of these Rake tasks do anything you could not do with `db:migrate`. They
 are simply more convenient, since you do not need to explicitly specify the
 version to migrate to.
 
+### Setup the Database
+
+The `rake db:setup` task will create the database, load the schema and initialize
+it with the seed data.
+
 ### Resetting the Database
 
-The `rake db:reset` task will drop the database, recreate it and load the
-current schema into it.
+The `rake db:reset` task will drop the database and set it up again. This is
+functionally equivalent to `rake db:drop db:setup`.
 
 NOTE: This is not the same as running all the migrations. It will only use the
-contents of the current schema.rb file. If a migration can't be rolled back,
-'rake db:reset' may not help you. To find out more about dumping the schema see
-'[schema dumping and you](#schema-dumping-and-you).'
+contents of the current `schema.rb` file. If a migration can't be rolled back,
+`rake db:reset` may not help you. To find out more about dumping the schema see
+[Schema Dumping and You](#schema-dumping-and-you) section.
 
 ### Running Specific Migrations
 
 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
@@ -751,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
@@ -831,8 +835,7 @@ which contains a `Product` model:
 Bob goes on vacation.
 
 Alice creates a migration for the `products` table which adds a new column and
-initializes it. She also adds a validation to the `Product` model for the new
-column.
+initializes it:
 
 ```ruby
 # db/migrate/20100513121110_add_flag_to_product.rb
@@ -843,11 +846,12 @@ class AddFlagToProduct < ActiveRecord::Migration
     reversible do |dir|
       dir.up { Product.update_all flag: false }
     end
-    Product.update_all flag: false
   end
 end
 ```
 
+She also adds a validation to the `Product` model for the new column:
+
 ```ruby
 # app/models/product.rb
 
@@ -856,9 +860,8 @@ class Product < ActiveRecord::Base
 end
 ```
 
-Alice adds a second migration which adds and initializes another column to the
-`products` table and also adds a validation to the `Product` model for the new
-column.
+Alice adds a second migration which adds another column to the `products`
+table and initializes it:
 
 ```ruby
 # db/migrate/20100515121110_add_fuzz_to_product.rb
@@ -873,11 +876,13 @@ class AddFuzzToProduct < ActiveRecord::Migration
 end
 ```
 
+She also adds a validation to the `Product` model for the new column:
+
 ```ruby
 # app/models/product.rb
 
 class Product < ActiveRecord::Base
-  validates :flag, inclusion:  { in: [true, false] }
+  validates :flag, inclusion: { in: [true, false] }
   validates :fuzz, presence: true
 end
 ```
@@ -906,7 +911,7 @@ A fix for this is to create a local model within the migration. This keeps
 Rails from running the validations, so that the migrations run to completion.
 
 When using a local model, it's a good idea to call
-`Product.reset_column_information` to refresh the `ActiveRecord` cache for the
+`Product.reset_column_information` to refresh the Active Record cache for the
 `Product` model prior to updating data in the database.
 
 If Alice had done this instead, there would have been no problem:
@@ -959,7 +964,7 @@ 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.
+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
@@ -1035,8 +1040,8 @@ this, then you should set the schema format to `:sql`.
 Instead of using Active Record's schema dumper, the database's structure will
 be dumped using a tool specific to the database (via the `db:structure:dump`
 Rake task) into `db/structure.sql`. For example, for PostgreSQL, the `pg_dump`
-utility is used. For MySQL, this file will contain the output of `SHOW CREATE
-TABLE` for the various tables.
+utility is used. For MySQL, this file will contain the output of
+`SHOW CREATE TABLE` for the various tables.
 
 Loading these schemas is simply a question of executing the SQL statements they
 contain. By definition, this will create a perfect copy of the database's