Some comments that are meant to separate blocks of code in a file show up
on http://api.rubyonrails.org as though they were part of the documentation.

This commit hides those comments from the documentation.

Stems from the discussion with @zzak at https://github.com/voloko/sdoc/issues/79#issuecomment-64158738

[ci skip]

Why are people assigning booleans to string columns? >_>

We unintentionally changed the behavior on Sqlite3 and PostgreSQL.
Boolean values should cast to the database's representation of true and
false. This is 't' and 'f' by default, and "1" and "0" on Mysql. The
implementation to make the connection adapter specific behavior is hacky
at best, and should be re-visted once we decide how we actually want to
separate the concerns related to things that should change based on the
database adapter.

That said, this isn't something I'd expect to change based on my
database adapter. We're storing a string, so the way the database
represents a boolean should be irrelevant. It also seems strange for us
to give booleans special behavior at all in string columns. Why is
`to_s` not sufficient? It's inconsistent and confusing. Perhaps we
should consider deprecating in the future.

Fixes #17571

The MySQLAdapter type map used the lowest priority for enum types.
This was the result of a recent refactoring and lead to some broken lookups
for enums with values that match other types. Like `8bit`.

This patch restores the priority to what we had before the refactoring.

/cc @sgrif

it doesn't work on SQLite3 since it doesn't support truncate, but that's
OK.  If you call truncate on the connection, you're now bound to that
database (same as if you use hstore or any other db specific feature).

`AbstractAdapter#supports_views?` defaults to `false` so we have to turn it on
in adapter subclasses. Currently the flag only controls test execution.

/cc @yahonda

Method .strip_heredoc is defined in
active_support/core_ext/string/strip.rb so we need to require it.

[fixes #16677]

Sets the connection collation to the database collation configured
in database.yml. Otherwise, `SET NAMES utf8mb4` will use the default
collation for that charset (utf8mb4_general_ci) when you may have chosen
a different collation, like utf8mb4_unicode_ci.

This only applies to literal string comparisons, not column values, so
it is unlikely to affect you.

As per discussion, this changes the model generators to specify
`null: false` for timestamp columns. A warning is now emitted if
`timestamps` is called without a `null` option specified, so we can
safely change the behavior when no option is specified in Rails 5.

We default to making the connection strict, but have historically relied
on the MySQL default when we want it to be non-strict. On some (recent?)
versions of MySQL, new connections default to being strict, so if we've
been told 'strict:false', we're obliged to pass that on.

This fixes a test failure that we've seen turn up on relatively-new
development machines, so we do already have a test covering it.

Making this change revealed several subtle bugs related to models with
no primary key, and anonymous classes. These have been fixed as well,
with regression tests added.

If we want to have type decorators mess with the attribute, but not the
column, we need to stop type casting on the column. Where possible, we
changed the tests to test the value of `column_defaults`, which is
public API. `Column#default` is not.

We need to decorate the types lazily. This is extracted to a separate
API, as there are other refactorings that will be able to make use of
it, and to allow unit testing the finer points more granularly.

- Create a consistent API across adapters for building new columns
- Use it for custom properties so we don't get `UndefinedMethodError`s
  in stuff I'm implementing elsewhere.

This is already the behavior for `BigDecimal` in the abstract adapter.

Columns and injected types no longer have any conditionals based on the
format of SQL type strings! Hooray!

All subclasses of column were now delegating `type_cast` to their
injected type object. We can remove the overriding methods, and
generalize it on the `Column` class itself. This also enabled us to
remove several column classes completely, as they no longer had any
meaningful behavior of their own.

The `:timestamp` type for columns is unused. All database adapters treat
them as the same database type. All code in `ActiveRecord` which changes
its behavior based on the column's type acts the same in both cases.
However, when the type is passed to code that checks for the `:datetime`
type, but not `:timestamp` (such as XML serialization), the result is
unexpected behavior.

Existing schema definitions will continue to work, and the `timestamp`
type is transparently aliased to `datetime`.

The decision to wrap type registrations in a proc was made for two
reasons.

1. Some cases need to make an additional decision based on the type
  (e.g. a `Decimal` with a 0 scale)
2. Aliased types are automatically updated if they type they point to is
  updated later. If a user or another adapter decides to change the
  object used for `decimal` columns, `numeric`, and `number` will
  automatically point to the new type, without having to track what
  types are aliased explicitly.

Everything else here should be pretty straightforward. PostgreSQL ranges
had to change slightly, since the `simplified_type` method is gone.

Part of #15134. In order to perform typecasting polymorphically, we need
to add another argument to the constructor. The order was chosen to
match the `oid_type` on `PostgreSQLColumn`.