order on the old ones

The previous behavior added a major backward incompatibility since it
impossible to have a upgrade path without major changes on the
application code.

We are taking the most conservative path to be consistent with the idea
of having a smoother upgrade on Rails 4.

We are reverting the behavior for what was in Rails 3.x and,
if needed, we will implement a new API to prepend the order clauses in
Rails 4.1.

`disable_implicit_join_references=` was only deprecated on `master`,
not with rails 4.0. We can remove it after 4.1

This reverts commit 3c719ead, reversing
changes made to d5c3bf97.

They were deprecated in 4.0, planned to remove in 4.1

Closes #9712.

We moved more and more away from passing options to finder / calculation
methods. The `:distinct` option in `#count` was one of the remaining places.
Since we can now combine `Relation#distinct` with `Relation#count` the option
is no longer necessary and can be deprecated.

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`.

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

This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.

In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.

The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:

  default_scope.merge(association_scope)

If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')

Now, the RHS of the merge is left alone.

Fixes #8990

They don't add any benefits over `assert object.blank?`
and `assert object.present?`

This reverts commit 162e2859.

This commit was added by mistake, sorry 🙇

- Reverting #a3cf03ef fixes the issue

Conflicts:
	activerecord/test/cases/relations_test.rb

At present, ActiveRecord::Delegation compiles delegation methods on a
global basis. The compiled methods apply to all subsequent Relation
instances. This creates several problems:

1) After Post.all.recent has been called, User.all.respond_to?(:recent)
   will be true, even if User.all.recent will actually raise an error due
   to no User.recent method existing. (See #8080.)

2) Depending on the AR class, the delegation should do different things.
   For example, if a Post.zip method exists, then Post.all.zip should call
   it. But this will then result in User.zip being called by a subsequent
   User.all.zip, even if User.zip does not exist, when in fact
   User.all.zip should call User.all.to_a.zip. (There are various
   variants of this problem.)

We are creating these compiled delegations in order to avoid method
missing and to avoid repeating logic on each invocation.

One way of handling these issues is to add additional checks in various
places to ensure we're doing the "right thing". However, this makes the
compiled methods signficantly slower. In which case, there's almost no
point in avoiding method_missing at all. (See #8127 for a proposed
solution which takes this approach.)

This is an alternative approach which involves creating a subclass of
ActiveRecord::Relation for each AR class represented. So, with this
patch, Post.all.class != User.all.class. This means that the delegations
are compiled for and only apply to a single AR class. A compiled method
for Post.all will not be invoked from User.all.

This solves the above issues without incurring significant performance
penalties. It's designed to be relatively seamless, however the downside
is a bit of complexity and potentially confusion for a user who thinks
that Post.all and User.all should be instances of the same class.

Benchmark
---------

require 'active_record'
require 'benchmark/ips'

class Post < ActiveRecord::Base
  establish_connection adapter: 'sqlite3', database: ':memory:'
  connection.create_table :posts

  def self.omg
    :omg
  end
end

relation = Post.all

Benchmark.ips do |r|
  r.report('delegation')   { relation.omg }
  r.report('constructing') { Post.all }
end

Before
------

Calculating -------------------------------------
          delegation      4392 i/100ms
        constructing      4780 i/100ms
-------------------------------------------------
          delegation   144235.9 (±27.7%) i/s -     663192 in   5.038075s
        constructing   182015.5 (±21.2%) i/s -     850840 in   5.005364s

After
-----

Calculating -------------------------------------
          delegation      6677 i/100ms
        constructing      6260 i/100ms
-------------------------------------------------
          delegation   166828.2 (±34.2%) i/s -     754501 in   5.001430s
        constructing   116575.5 (±18.6%) i/s -     563400 in   5.036690s

Comments
--------

Bear in mind that the standard deviations in the above are huge, so we
can't compare the numbers too directly. However, we can conclude that
Relation construction has become a little slower (as we'd expect), but
not by a huge huge amount, and we can still construct a large number of
Relations quite quickly.

This didn't work in rails 3.1. See #2303 for more information and original pull request.

This is similar to #first_or_create, but slightly different and a nicer
API. See the CHANGELOG/docs in the commit.

Fixes #7853

This is a cleaner version of #6916.

Closes #3165.

This is a real fix (as compared to the band-aid in b127d86c), which uses
the recently-added equality methods for ARel nodes. It has the side
benefit of simplifying the merge code a bit.

This is at best a band-aid for a more proper fix, since it won't truly
handle the removal of the previous equality condition of these other
nodes. I'm planning to put in some work on ARel toward supporting that
goal.

Related: rails/arel#130, ernie/squeel#153, ernie/squeel#156

On reflection, it seems like a bit of a weird method to have on
ActiveRecord::Base, and it shouldn't be needed most of the time anyway.

This method explicitly loads the records and then returns `self`.

Rather than deciding between "do I want an array or a relation?",
most people are actually asking themselves "do I want to eager load
or lazy load?" Therefore, this method provides a way to explicitly
eager-load without having to switch from a `Relation` to an array.

Example:

    @posts = Post.where(published: true).load

    User.order("name asc").order("created_at desc")
    # SELECT * FROM users ORDER BY created_at desc, name asc

This also affects order defined in `default_scope` or any kind of associations.

It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.

The code is moved to active_record_deprecated_finders.