Currently `exists?` does some hackery where it assumes that we can join
onto anything that we passed to `eager_load` or `includes`, which
doesn't work if we are joining onto a polymorphic association.

Actually figuring out if we want to include something would require
knowledge deep within the join dependency module, which is hard to pull
up. The simplest solution is just to pass a flag down that says we're
not actually going to try to eager load any of the data. It's not the
solution I'd like, but that code really needs to be untangled before we
can do much with it.

This is another attempt at 6d5b1fdf which should address the concerns
that led to reverting it in 4ecabed2.

`association_for_table` is unused since 50a8cdf0.

Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005

* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.

In 5.0 we use bind parameters for limit and offset, while in 4.2 we used
the values directly. The code as it was written assumed that limit and
offset worked as `LIMIT ? OFFSET ?`. Both Oracle and SQL Server have a
different syntax, where the offset is stated before the limit. We
delegate this behavior to the connection adapter so that these adapters
are able to determine how the bind parameters are flattened based on
what order their specification has the various clauses appear.

Fixes #24775

Passing conditions to `#destroy_all` was deprecated in c82c5f8f.

Don't create new arrays when trying to compute non_empty_predicates for where clause predicate. Get a 3-4% improvement in AST generation.
Perf compare: https://gist.github.com/vipulnsward/7e4e9ecb157e574002313249a7969c82

In 04ac5655 I assumed that we would
never want to pass the "table_name.column_name" form to where with a
symbol. However, in Ruby 2.2 and later, you can quote symbols using the
new hash syntax, so it's a semi-reasonable thing to do if we want to
support the dot notation (which I'd rather deprecate, but that would be
too painful of a migration).

Instead we've changed the definition of "this is a table name with a
dot" to when the value associated is a hash. It would make very little
sense to write `where("table_name.column_name": { foo: :bar })` in any
scenario (other than equality for a JSON column which we don't support
through `where` in this way).

Close #24514.

- we are ending sentences properly
- fixing of space issues
- fixed continuity issues in some sentences.

Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 .
This change reverts making sure we add '.' at end of deprecation sentences.
This is to keep sentences within Rails itself consistent and with a '.' at the end.

This issue occured because associations now call `where` directly, and a
dot in the key name for `where` means nested tables. For this fix, we
now pass the table name as a symbol, and do not attempt to expand
symbols containing a dot.

This is a temporary fix. I do not think we should support table names
containing a dot, as it has a special meaning in most backends, as well
as most APIs that involve table names. This commit does not include a
test, as I am going to deprecate table names containing dots in the
following commit.

Fixes #24367

found these commits https://github.com/rails/rails/commit/9cc8c6f3730df3d94c81a55be9ee1b7b4ffd29f6, https://github.com/rails/rails/commit/9d79334a1dee67e31222c790e231772deafcaeb8 that also should remove it.

We should use #find_or_initialize_by and #find_or_create_by because #first_or_initialize and #first_or_create methods are not the public API

Clarifying this separation and enforcing relation immutability is the
culmination of the previous efforts to remove the mutator method
delegations.

Delegation of some `Array` methods was removed in commit 9d79334a. That
change did add explicit delegation of a few methods that `Array` has but
which aren't on `Enumerable`.  However, a few non-mutation methods were
omitted.  This adds `Array` delegation of `#in_groups`, `#in_groups_of`,
`#shuffle` and `#split`.  This allows things like
`MyThing.all.in_groups_of(3) { ... }` to continue working as they did
before commit 9d79334a.

- Previously it used to show error message
    <"undefined method `limit_value' for {:title=>\"Rails\"}:Hash">

- Now it shows following error message.

    >> Post.where.not(name: 'DHH').or(name: 'Tenderlove')
    ArgumentError: You have passed Hash object to #or. Pass an ActiveRecord::Relation object instead.

- Fixes #23714.

When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array.

    PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
	# => SELECT "price_estimates".* FROM "price_estimates"
         WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2))

This is fixed to properly look for any records matching both type and id:

    PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)])
    # => SELECT "price_estimates".* FROM "price_estimates"
         WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1)
         OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))

instead of loading the relation into memory

This removes the following warnings.

```
activerecord/lib/active_record/relation/finder_methods.rb:252: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:258: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:268: warning: ambiguous first argument; put parentheses or a space even after `-' operator
activerecord/lib/active_record/relation/finder_methods.rb:274: warning: ambiguous first argument; put parentheses or a space even after `-' operator
```

This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.

add some documentation and add 4 tests regarding error vs. warning behavior

fix a typo when referring to the message

go back to default in tests so that ordering is not important. use a constant instead of method. fix assert_nothing_raised call. use self.klass to allow per class configuration

remove logger warn assets as that is tested elsewhere. pass error_on_ignore through find_each and find_in_batches also.

add blocks to the finds so that the code is actually executed

put the setting back to default in an ensure

Add a changelog entry

This reverts commit 9f3730a5, reversing
changes made to 2637fb75.

There are additional issues with this commit that need to be addressed
before this change is ready (see #23377). This is a temporary revert in
order for us to have more time to address the issues with that PR,
without blocking the release of beta2.

instead of loading relation

@bogdan pointed out that a `loaded?` relation would not warn that the supplied
offset would be removed. This fixes that oversight.

https://github.com/rails/rails/commit/16a476e4f8f802774ae7c8dca2e59f4e672dc591#commitcomment-15706834

Although this second argument is probably not widely used, and would be
ignored anyway in the loaded? case, this could protect callers from gotchas.

[Ben Woosley & Victor Kmita]

Raises when #reverse_order can not process SQL order instead of making
invalid SQL before this patch

This is a similar case to wanting ot use bind params for limit and
offset. Right now passing a range grows the amount of prepared
statements in an unbounded fashion. We could avoid using prepared
statements in that case, similar to what we do with arrays, but there's
a known number of variants for ranges.

This ends up duplicating some of the logic from Arel for how to handle
potentially infinite ranges, and that behavior may be removed from Arel
in the future.

Fixes #23074

Changed options for find_each and variants to have options start/finish instead of start_at/end_at based on comments
at https://github.com/rails/rails/pull/12257#issuecomment-74688344

The code that set the from clause was removed in
bdc51416. I did not give any reason for
doing so. My assumption was that I intended to change it to use the
clause objects, but forgot. We appeared to not have test coverage for
this case.

Fixes #22996

When you are using scopes and you chaining these scopes it is hard to
know which are the values that are incompatible. This way you can read
the message and know for which values you need to look for.

[Herminio Torres]

This reverts commit 5d41cb3b.

This implementation does not properly handle cases involving predicates
which are not associated with a bind param. I have the fix in mind, but
don't have time to implement just yet. It will be more similar to #22823
than not.

While the predicates are an arel equality node where the left side is a
full arel attribute, the binds just have the name of the column and
nothing else. This means that while splitting the predicates can include
the table as a factor, the binds cannot. It's entirely possible that we
might be able to have the bind params carry a bit more information (I
don't believe the name is used for anything but logging), and that is
probably a worthwhile change to make in the future.

However the simplest (and likely slightly faster) solution is to simply
use the indices of the conflicts in both cases. This means that we only
have to compute the collision space once, instead of twice even though
we're doing an additional array iteration. Regardless, this method isn't
a performance hotspot.

Close #22823.

[Ben Woosley & Sean Griffin]