* Clarify what the situation is and what to do.
* Advise loading schema using `rake db:setup` instead of migrating.
* Use a rescue in the initializer rather than extending the error
  message in-place.
* Preserve the original backtrace of other errors by using `raise`
  rather than raising again with `raise error`.

References 0ec45cd1

This was a common pattern:
```
query = author.posts.select(:title)
connection.select_one(query)
```

However `.select` returns a ActiveRecord::AssociationRelation, which has
the bind information, so we can use that to get the right sql query.

Also fix select_rows on postgress and sqlite3 that were not using the binds

[fixes #7538]
[fixes #12017]
[related #13731]
[related #12056]

Building on the work of #13427 this PR adds a helpful error message to the adapters: mysql, mysql2, and sqlite3

    
This has returned true since 3cc9b5f1, and is not used internally.

Drop some comments that document the implementation rather than the interface.

The log output used to be confusing in situation where type casting has
"unexpected" effects. For example when finding records with a `String`.

BEFORE:

irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- :   Event Load (4.5ms)  SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1  [["id", "im-no-integer"]]

AFTER:

irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- :   Event Load (4.5ms)  SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1  [["id", 0]]

Remove `default_primary_key_type`  and extract contains of `native_database_types` to a constant since they aren't conditional now in SQLite3Adapter. Makes it more like other adapters.

When the adapter is with prepared statement disabled and the binds array
is not empty the connection adapter will try to set the binds values and
will fail. Now we are checking if the adapter has the prepared statement
disabled.

Fixes #12023

This change was breaking the Railties tests. See
https://travis-ci.org/rails/rails/jobs/9865969

If the `db/` directory is not present on a remote machine it will blow up in unexpected ways with error messages that do not indicate there is a missing directory:

```
SQLite3::CantOpenException: unable to open database file
```

This PR checks to see if a directory exists for the sqlite3 file and if not creates it for you.

This PR is an alternative to #11692 as suggested by @josevalim

added comments to test_invalid_type in sqlite3 adapter test and added valid_type? method to abstract_adapter.rb and removed unnecessary method from sqlite3 adapter

Created a layer of abstraction for the valid type checking in schema dumper. Now, connection handles the check for valid types so that each database can handle the changes individually.

To make quote escape binary data correctly it needs the column passed in.

We should only type cast when we need to use.

Related to 4b005fb3

When a table or a column is renamed related indexes kept their name. This will lead to confusing names. This patch renames related indexes when a column or a table is renamed. Only indexes with names generated by rails will be renamed. Indexes with custom names will not be renamed.

Some adapter (SQLite3) need to perform renaming operations to support
the rails DDL. These rename prefixes operate with prefixes. When an
index name already uses up the full space provieded by
`index_name_length` these internal operations will fail. This patch
introduces `allowed_index_name_length` which respects the amount of
characters used for internal operations. It will always be <=
`index_name_length` and every adapter can define how many characters
need to be reserved.

It was supposed to be removed by the preceding two reversions but I did
them in the wrong order.

This reverts commit 5d528f83.

Relates to f8c8ad56 which is also getting reverted due to failing test.

because of an ambiguous column name. This happened if the association
model had a default scope that referenced a third table, and the third
table also referenced the original table (with an identical
foreign_key).

Mysql requires that ambiguous columns are deambiguated by using the full
table.column syntax. Postgresql and Sqlite use a different syntax for
updates altogether (and don't tolerate table.name syntax), so the fix
requires always including the full table.column and discarding it later
for Sqlite and Postgresql.

[#8267]

When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.

This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).

Fixes #7374