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

Fix: habtm doesn't respect select query method

CollectionProxy#replace should change the DB records rather than just mutating the array. Fixes #3020.

Ensure we are not comparing a string with a symbol in HasManyAssociation#inverse_updates_counter_cache?. Fixes #2755, where a counter cache could be decremented twice as far as it was supposed to be.

In order to make CollectionAssociation behave closer to Array
Add the ability to pass block to #find method just like Array#find does.

Assign the association attributes to the associated record before the before_initialize callback of the record runs. Fixes #1842.

Make assert_no_queries literally enforce that there are no queries. As in, not a single line of SQL should be sent to the database, not even stuff that is ignored by assert_queries. The argument being that if you write assert_no_queries, you really do not want there to be any queries.