This matches our behavior in other cases where useful enumerable methods
might have a different definition in `Relation`. Wanting to actually
enumerate over the records in this case is completely reasonable, and
wanting `.sum` is reasonable for the same reason it is on `Enumerable`
in the first place.

Our general contract in Active Record is that strings are assumed to be
SQL literals, and symbols are assumed to reference a column. If a from
clause is given, we shouldn't include the table name, but we should
still quote the value as if it were a column.

Upon fixing this, the tests were still failing on SQLite. This was
because the column name being returned by the query was `"\"join\""`
instead of `"join"`. This is actually a bug in SQLite that was fixed a
long time ago, but I was using the version of SQLite included by OS X
which has this bug. Since I'm guessing this will be a common case for
contributors, I also added an explicit check with a more helpful error
message.

Fixes #20360

This allows easier integration with ActiveRecord, such that
AR#pluck will now use Enumerable#pluck if the relation is loaded,
without needing to hit the database.

Couldn't find other way to get the association name from a given class
other than looping through `reflect_on_all_associations` reflections ..

Noticed this one while looking at this example:

```ruby
class Product < ActiveRecord::Base
  has_many :variants
  has_many :translations
end

class Translation < ActiveRecord::Base
  belongs_to :product
end

class Variant < ActiveRecord::Base
  belongs_to :product
end

class BugTest < Minitest::Test
  def test_merge_stuff
    product = Product.create! name: 'huhu'
    variant = Variant.create! product_id: product.id
    Translation.create! locale: 'en', product_id: product.id

    product_relation = Product.all
                              .preload(:translations)
                              .joins(:translations)
                              .merge(Translation.where(locale: 'en'))
                              .where(name: 'huhu')

    assert_equal variant, Variant.joins(:product).merge(product_relation).first
  end
end
```

See #9683 for the reasons we switched to `distinct`.

Here is the discussion that triggered the actual deprecation #20198.

`uniq`, `uniq!` and `uniq_value` are still around.
They will be removed in the next minor release after Rails 5.

Stems from https://github.com/rails/rails/pull/20105#issuecomment-100900939
where @senny said:

> From my point of view, all the docs (guides, API) are version bound.
> They should describe that version and continue to be available when newer versions are released.
> The cross referencing can be done by the interested user.

Now that master points at Rails 5, we might not need to explain how
things used to work in Rails 3. Or we might… up to you 😁

This reverts commit 524d4059, reversing
changes made to 34d3a609.

Reasoning behind the revert are in the PR discussion:
https://github.com/rails/rails/pull/19755

- This means that types can no longer cast to/from `Set`, and reasonably
  work with `where` (we already have this problem for `array`/`json`
  types on pg)
- This adds precedent for every other `Enumerable`, and we can't target
  `Enumerable` directly.
- Calling `to_a` on a `Set` is reasonable.

Previously `#where` used to treat `Set`objects as nil, but now it treats
them as an array:

  set = Set.new([1, 2])
  Author.where(:id => set)
  # => SELECT "authors".* FROM "authors" WHERE "authors"."id" IN (1, 2)

Documentation is giving an example that can be replaced by a more dry command.
Give a hint that ids can be used instead of pluck(:id).

It fixes the strange error saying undefined method `take'.

```
RelationTest#test_find_by_without_arg_behaves_same_with_find_by({}):
NoMethodError: undefined method `take' for #<ActiveRecord::QueryMethods::WhereChain:0x007f9c55db1d68>
```

Code such as the following will be corrected.

    Developer.where(id: -Float::INFINITY...2).unscope(where: :id)

- ‘dection’ -> ‘detection’

- ‘exceeds threshold’ -> ‘exceeds the threshold’

- Other minor improvements.

When set to an integer, a warning will be logged whenever a result set
larger than the specified size is returned by a query. Fixes #16463

The warning is outputed a module which is prepended in an initializer,
so there will be no performance impact if
`config.active_record.warn_on_records_fetched_greater_than` is not set.

association

While joining table of has_many :through association, ActiveRecord will
use the actual table name instead of through-join alias. It results with
a wrong SQL and exception is raised. This only happens when calculation
methods like #count is called.

This issue is affecting Rails 4.1.x and 4.2.x as well.

It is redundant with tests in `eager_loading?`, but for the difference
between `includes_values.present?` and `includes_values.any?`, which
is a difference without a distinction because `false` has no meaning
for `includes`.

[ci skip]

Removed non-standard and unused require 'active_support/deprecation' from parts out of active_support.

Fix c4794806 to account for from_value -> from_clause in bdc51416

Fix appending table_name to select and group when used with subquery (fr...

Deprecated passing of `start` value to `find_in_batches` and `find_each` in favour of `begin_at` value.

that complements the `start`parameter to specify where to stop batch processing

nil or false should not be valid argument to the merge method.

Closes #12264

We already validate the keys, so it is better to use the built-in
feature to do this

While we query the proper columns, we go through normal handling for
converting the value to a primitive which assumes it should use the
table's primary key. If the association specifies a different value (and
we know that we're working with an association), we should use the
custom primary key instead.

Fixes #18813.

It's finally finished!!!!!!! The reason the Attributes API was kept
private in 4.2 was due to some publicly visible implementation details.
It was previously implemented by overloading `columns` and
`columns_hash`, to make them return column objects which were modified
with the attribute information.

This meant that those methods LIED! We didn't change the database
schema. We changed the attribute information on the class. That is
wrong! It should be the other way around, where schema loading just
calls the attributes API for you. And now it does!

Yes, this means that there is nothing that happens in automatic schema
loading that you couldn't manually do yourself. (There's still some
funky cases where we hit the connection adapter that I need to handle,
before we can turn off automatic schema detection entirely.)

There were a few weird test failures caused by this that had to be
fixed. The main source came from the fact that the attribute methods are
now defined in terms of `attribute_names`, which has a clause like
`return [] unless table_exists?`. I don't *think* this is an issue,
since the only place this caused failures were in a fake adapter which
didn't override `table_exists?`.

Additionally, there were a few cases where tests were failing because a
migration was run, but the model was not reloaded. I'm not sure why
these started failing from this change, I might need to clear an
additional cache in `reload_schema_from_cache`. Again, since this is not
normal usage, and it's expected that `reset_column_information` will be
called after the table is modified, I don't think it's a problem.

Still, test failures that were unrelated to the change are worrying, and
I need to dig into them further.

Finally, I spent a lot of time debugging issues with the mutex used in
`define_attribute_methods`. I think we can just remove that method
entirely, and define the attribute methods *manually* in the call to
`define_attribute`, which would simplify the code *tremendously*.

Ok. now to make this damn thing public, and work on moving it up to
Active Model.

Fixes #18717

    Post.where('id = 1').or(Post.where('id = 2'))
    # => SELECT * FROM posts WHERE (id = 1) OR (id = 2)

[Matthew Draper & Gael Muller]

`bound_attributes` is now used universally across the board, removing
the need for the conversion layer. These changes are mostly mechanical,
with the exception of the log subscriber. Additional, we had to
implement `hash` on the attribute objects, so they could be used as a
key for query caching.

The column is primarily used for type casting, which we're trying to
separate from the idea of a column. Since what we really need is the
combination of a name, type, and value, let's use the object that we
already have to represent that concept, rather than this tuple. No
consumers of the bind values have been changed, only the producers
(outside of tests which care too much about internals). This is
*finally* possible since the bind values are now produced from a
reasonable number of lcoations.

Attempting to grok this code by refactoring it as I go through it.