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.

Previously it returned an Array.

If you want an array, call e.g. `Post.to_a` rather than `Post.all`. This
is more explicit.

In most cases this should not break existing code, since
Relations use method_missing to delegate unknown methods to #to_a
anyway.

Closes #1190

now everything is converted to the new style, this is not needed

I found the next issue between CollectionAssociation `delete`
and `destroy`.

    class Person < ActiveRecord::Base
      has_many :pets
    end

    person.pets.destroy(1)
    # => OK, returns the destroyed object

    person.pets.destroy("2")
    # => OK, returns the destroyed object

    person.pets.delete(1)
    # => ActiveRecord::AssociationTypeMismatch

    person.pets.delete("2")
    # => ActiveRecord::AssociationTypeMismatch

Adding support for deleting with a fixnum or string like
`destroy` method.

The core of this fix is a threadsafe, fair Queue class.  It is
very similar to Queue in stdlib except that it supports waiting
with a timeout.

The issue this solves is that if several threads are contending for
database connections, an unfair queue makes is possible that a thread
will timeout even while other threads successfully acquire and release
connections.  A fair queue means the thread that has been waiting the
longest will get the next available connection.

This includes a few test fixes to avoid test ordering issues that
cropped up during development of this patch.

The fix commited in e2a070cf was returning the `new_target`, as
a try to return whatever user replaced association with. The
problem is, the resulting association target may be ordered
differently. In such case we want to return the target that
will be later used for that association.

Bug #6289

Makes it consistent with Relation. Can't see a use for this.

This helps bring the interfaces of CollectionProxy and Relation closer
together, and reduces the delegation backflips we need to perform.

For example, first_or_create is defined thus:

class ActiveRecord::Relation
  def first_or_create(...)
    first || create(...)
  end
end

If CollectionProxy < Relation, then post.comments.first_or_create will
hit the association's #create method which will actually add the new record
to the association, just as post.comments.create would.

With the previous delegation, post.comments.first_or_create expands to
post.comments.scoped.first_or_create, where post.comments.scoped has no
knowledge of the association.

Change CollectionProxy#method_missing to use scoped.public_send, to
avoid a problem described in issue #2508 when trying to use class
methods with names like "open", that clash with private kernel methods.
Also changed the dynamic matcher instantiator to send straight to
scoped, to avoid another roundtrip to method_missing.

load has_many associations keyed off a custom primary key if that key is present but the record is unsaved

Preserve SELECT columns on the COUNT for finder_sql when possible