We know the query will return exactly one row for each entry in the
`ids` array, so we can do all the limit/offset calculations on that
array, in advance.

I also split our new ordered-ids behaviour out of the existing
`find_some` method: especially with this change, the conditionals were
overwhelming the actual logic.

do not change the order of the result if the object was already ordered by the user via :order clause

If there is a method defined such as `find_and_do_stuff(id)`, which then
gets called on an association, we will perform statement caching and the
parent ID will not change on subsequent calls.

Fixes #18117

This ensures that we're handling all forms of nested tables the same way.

We're aware that the `convert_dot_notation_to_hash` method will cause a
performance hit, and we intend to come back to it once we've refactored some of
the surrounding code.

[Melissa Xie & Melanie Gilman]

`Computer` class needs to be require

See #17217 for more details

We should not behave differently just because a class has a default
scope.

Sufficiently large integers cause `find` and `find_by` to raise
`StatementInvalid` instead of `RecordNotFound` or just returning `nil`.
Given that we can't cast to `nil` for `Integer` like we would with junk
data for other types, we raise a `RangeError` instead, and rescue in
places where it would be highly unexpected to get an exception from
casting.

Fixes #17380

For now, we will just skip the cache when a non-column key is used in the hash.
If the future, we can probably move some of the logic in PredicateBuilder.expand
up the chain to make caching possible for association queries.

Closes #16903
Fixes #16884

`User.where(id: [[1,2],3])` was equal to `User.where(id:[1, 2, 3])`
in Rails 4.1.x but because of some refactoring in Arel this stopped
working in 4.2.0. This fixes it in Rails.

[Dan Olson & Cristian Bica]

* Also duplicated find_by tests from relations_test.rb to finder_test.rb now
	that we have a completely different implementation on the class (in core.rb
	with AST caching stuff).

* Also removed a (failing) test that used mocks. Now that we have tests for the
  behavior, there's no point having another test that tests the implementation
	(that it delegates). Further, what the test was implying is nolonger true with
	the current implementation, because Class.find_by is a real method now.

Fixes #15821.

Looks like #first wasn't warm enough...

Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.

As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.

Model that the Record was not found in.

```
activerecord/test/cases/adapters/postgresql/range_test.rb:159: warning: (...) interpreted as grouped expression
activerecord/test/cases/finder_test.rb:38: warning: shadowing outer local variable - e
activerecord/test/cases/finder_test.rb:43: warning: shadowing outer local variable - e
```

`exists?`

Pass the id of the object to the method by calling `.id` on the AR
object.

This will avoid the confusing flunk logic

When we build a query with an inline value that is a numeric (e.g.
because it's out of range for an int4) PostgreSQL doesn't use an index
on the column, since it's now comparing numerics and not int4s.

This leads to a _very_ slow query.

When we use bound parameters instead of inline values PostgreSQL
raises numeric_value_out_of_range since no automatic coercion happens.

This commit fixes two regressions introduced in cafe31a0 where
newly created finder methods #second, #third, #forth, and #fifth
caused a NoMethodError error on reload associations and where we
were pulling the wrong element out of cached associations.

Examples:

  some_book.authors.reload.second

  # Before
  # => NoMethodError: undefined method 'first' for nil:NilClass

  # After
  # => #<Author id: 2, name: "Sally Second", ...>

  some_book.first.authors.first
  some_book.first.authors.second

  # Before
  # => #<Author id: 1, name: "Freddy First", ...>
  # => #<Author id: 1, name: "Freddy First", ...>

  # After
  # => #<Author id: 1, name: "Freddy First", ...>
  # => #<Author id: 2, name: "Sally Second", ...>

Fixes #13783.

This commit bring the famous ordinal Array instance methods defined
in ActiveSupport into ActiveRecord as fully-fledged finders.

These finders ensure a default ascending order of the table's primary
key, and utilize the OFFSET SQL verb to locate the user's desired
record. If an offset is defined in the query, calling #second adds
to the offset to get the actual desired record.

Fixes #13743.

This will fix the [broken
test](https://github.com/rails/rails/commit/4a2650836680f51490e999c3c8441a2f9adff96e)
 `test_with_limiting_with_custom_select`.

The query's result was built in a hash with column name as key, if the
result have a duplicated column name the last value was
overriding the first one.

The dynamic finder was creating the method signature with the parameters name,
which may have reserved words and this way creating invalid Ruby code.

Closes: #13261

    Example:

        # Before
        Dog.find_by_alias('dog name')

        # Was creating this method
        def self.find_by_alias(alias, options = {})

        # After
        Dog.find_by_alias('dog name')

        # Will create this method
        def self.find_by_alias(_alias, options = {})