fixes #10669

While joining_values special treatment is given to string values.
By flattening the array it ensures that string values are detected
as strings and not arrays.

pass block directly to grep

[ci skip]

The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our
Relation API is close to SQL terms I renamed `#uniq` to `#distinct`.

There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue
to work. I also updated the documentation to promote the use of `#distinct`.

relations. Specific where values can be unscoped, and the unscope method
still works when relations are merged or combined.

Fixes #9275.

When `#order` is called with a Symbol this patch will prepend the quoted_table_name.
Before the postgresql adapter failed to build queries containg a join and an order
with a symbol.

This expansion happens for all adapters.

Taking the wise advice of @carlosantoniodasilva

The function is now called has_arguments? so that it's easier to tell
that it's just checking to see if the args are blank or not.

for query methods in a where_clause. Also, modified the CHANGELOG entry
because it had false information and added tests.

* Fix example queries
* Remove doc entries of where.like/not_like.
* Remove :chain from where.not related docs. To me that's an implementation
  detail and we don't expect people to use where(:chain).not.

The real win with these chain methods is where.not, that takes care of
different scenarios in a graceful way, for instance when the given value
is nil.

    where("author.id != ?", author_to_ignore.id)
    where.not("author.id", author_to_ignore.id)

Both where.like and where.not_like compared to the SQL versions doesn't
seem to give us that much:

    Post.where("title LIKE 'ruby on%'")
    Post.where.like(title: 'ruby on%'")
    Post.where("title NOT LIKE 'ruby on%'")
    Post.where.not_like(title: 'ruby on%'")

Thus Rails is adding where.not, but not where.like/not_like and others.

This commit stems from https://github.com/rails/rails/pull/8332#issuecomment-11127957

Since the formats in which conditions can be passed to `not` differ
from the formats in which conditions can be passed to `like` and `not_like`,
then I think it's worth adding rdoc and tests to show this behavior

Arel::Nodes::In inherits from Arel::Nodes::Equality, so the case
statement was always using the Equality operator for both scenarios,
resulting in a not equal query instead.

This commit updates the rdoc of AR#where to match the changes applied
in https://github.com/rails/rails/commit/6ba0f97 that is:

* `where(nil)` has the same effect of `where('')`: a no op
* `where` (no args) has the same effect of `where(:chain)`: to create a WhereChain

Consider this scenario:

    if params[:foo]
      conditions = { foo: true }
    end

    foos = Foo.where(conditions).order(:id)

When params[:foo] is nil, this would call:

    foos = Foo.where(nil).order(:id)

In this scenario, we want Foo.where(conditions) to be the same as calling
Foo.all, otherwise we'd get a "NoMethodError order for WhereChain".

Related to #8332.

These are for internal use only and cannot be relied on as part of the
public API. See discussion on 8c2c6051.

examples:

  Model.where.not field: nil
  #=> "SELECT * FROM models WHERE field IS NOT NULL

  Model.where.like name: 'Jeremy%'
  #=> "SELECT * FROM models WHERE name LIKE 'Jeremy%'

this feature was originally suggested by Jeremy Kemper https://github.com/rails/rails/pull/5950#issuecomment-5591330

Closes #5950

allocations

Before:

Calculating -------------------------------------
                  ar        87 i/100ms
-------------------------------------------------
                  ar      823.4 (±11.8%) i/s -       4089 in   5.070234s

After:

Calculating -------------------------------------
                  ar        88 i/100ms
-------------------------------------------------
                  ar      894.1 (±3.9%) i/s -       4488 in   5.028161s

Same test as 3a6dfca7