In order to better facilitate refactoring, most places that mutated
`bind_values` have already been removed. One last spot snuck through.
Since we're no longer mutating the array, it also does not need to be
duped in `initialize_copy`.

This is cropping up all over the place. After a brief dive, I'm really
not sure why we have `arel.bind_values` at all. A cursory grep didn't
reveal where they're actually being assigned (it's definitely in AR, not
in Arel). I'd like to dig further into it, as I'm fairly certain we
don't actually need it, we just need a way for the predicate builder to
communicate merged binds upstream.

Fixes #18414

This adresses https://github.com/rails/rails/commit/1b7aa62b184c4410c99208f71b59bbac5c5f03be#commitcomment-9147803

This commit fixes the following case.

    User.where(User.arel_table[:created_at].lteq(1.year.ago)).unscope(where :created_at)

`where_sql` now requires that we pass it an engine. None of the manager
classes take an engine in their constructor.

We never actually make use of it on the table, since we're constructing
the select manager manually. It looks like if we ever actually were
grabbing it from the table, we're grossly misusing it since it's meant
to vary by AR class.

Its existence on `Arel::Table` appears to be purely for convenience
methods that are never used outside of tests. However, in production
code it just complicates construction of the tables on the rails side,
and the plan is to remove it from `Arel::Table` entirely. I'm not
convinced it needs to live on `SelectManager`, etc either.

on the joined assoiciation

Arel handles this for us automatically. Updated tests, as BindParam is
no longer a subclass of SqlLiteral. We should remove the second argument
to substitute_at entirely, as it's no longer used

We need to re-order the bind parameters since the AST returned by the
relation will have the where statement as the first bp, which breaks on
PG.

In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.

There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)

[Melanie Gilman & Sean Griffin]

We end up re-ordering them either way when we construct the Arel AST (in order
to deal with rewhere, etc), so we shouldn't bother giving it a number in the
first place beforehand.

The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.

Heredocs have better readability, and with `squish` we can still
produce a single line.

This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.

[Matthew Draper & Yves Senn]

Closes #16860. (pull request to discuss the implementation)

Using heredoc would enforce line wrapping to whatever column width we decided to
use in the code, making it difficult for the users to read on some consoles.

This does make the source code read slightly worse and a bit more error-prone,
but this seems like a fair price to pay since the primary purpose for these
messages are for the users to read and the code will not stick around for too
long.

If the request parameters are passed to create_with and where they can
be used to do mass assignment when used in combination with
Relation#create.

Fixes CVE-2014-3514

Conflicts:
	activerecord/lib/active_record/relation/query_methods.rb

Example:

  Author.where(posts: { author_id: Author.where(country_id: 1) }).joins(:posts)

It seems that #where! is not designed to be used as a chained where.
See initial implementation at 8c2c6051.
So, no need to check twice.

We should not test #where!

https://github.com/rails/rails/pull/15285#discussion_r13018316

/cc @tenderlove

Fixes #14752

Select mimics the block interface of arrays, but does not mock the
block interface for select!. This change moves the api to be a
private method, _select!.

The reverse_order method was using a flag to control if the order should
be reversed or not. Instead of using this variable just build the reverse order
inside its proper method.

This implementation was leading to an unexpected behavior when using
reverse_order and then applying reorder(nil).

Example:
  Before
    Post.order(:name).reverse_order.reorder(nil)
    # => SELECT "posts".* FROM "posts"   ORDER BY "posts"."id" DESC

  After
    Post.order(:name).reverse_order.reorder(nil)
   # => SELECT "posts".* FROM "posts"

The group method also takes an array, however this isn't immediately
clear by reading the source since it delegates this method. If you
trace it back to the AREL building you can see that it does support
an array.

Shoutout to @betovelandia for pointing this out.

Closes #14406.

origin: https://github.com/rails/rails/commit/f6aeb8b1a3687c8523e4a56309fe3736011b2935#commitcomment-5569649

This is a result of the discussion at https://github.com/rails/rails/pull/14263/files#r10291489

This behavior has almost no performance impact:

String not allowed  66.910000   0.030000  66.940000 ( 67.024976)
String allowed      69.360000   0.030000  69.390000 ( 69.503096)

Benchmarked with http://git.io/Y0YuRw.

This reverts commit 3ea84035, reversing
changes made to e4cde5d5.

Conflicts:
	activerecord/CHANGELOG.md
	activerecord/lib/active_record/relation/query_methods.rb

Reason: using `from` without `select` should not change the select list
to SELECT * because it can lead different query results. If it is needed
to change the table to a subquery or a view you can pass a table alias
in the `from` call or use `select('subquery.*')`.

Fixes #14049.

Since its conception arel was made to be private API of Active Record.
If users want to use arel features directly we should provide a way
using the Active Record API without exposing the arel implementation.

There is no gain in `referencing` tables that are not used for preloading.
Furthermore it will break if polymorphic associations are invloved. This
is because `references_eager_loaded_tables?` uses all `reference_values`
to decide wether to `eager_load` or `preload`.