Method `delete_all` should not be invoking callbacks and this
feature was deprecated in Rails 4.0. This is being removed.
`delete_all` will continue to honor the `:dependent` option. However
if `:dependent` value is `:destroy` then the default deletion
strategy for that collection will be applied.

User can also force a deletion strategy by passing parameter to
`delete_all`. For example you can do `@post.comments.delete_all(:nullify)`

Don't use this:

    scope :red, where(color: 'red')
    default_scope where(color: 'red')

Use this:

    scope :red, -> { where(color: 'red') }
    default_scope { where(color: 'red') }

The former has numerous issues. It is a common newbie gotcha to do
the following:

    scope :recent, where(published_at: Time.now - 2.weeks)

Or a more subtle variant:

    scope :recent, -> { where(published_at: Time.now - 2.weeks) }
    scope :recent_red, recent.where(color: 'red')

Eager scopes are also very complex to implement within Active
Record, and there are still bugs. For example, the following does
not do what you expect:

    scope :remove_conditions, except(:where)
    where(...).remove_conditions # => still has conditions

Test polymorphic record with optimistic locking and counter cache should be destoyed without catching the ActiveRecord::StaleObjectError.

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.

Don't use mass-assignment protection when setting foreign keys or association conditions on singular associations. Fixes #481 (again).

Add test to specify that attributes from an association's conditions should be assigned without mass-assignment protection when a record is built on the association.

Un-deprecate using 'default_scope' as a macro, but if you are calling the macro multiple times that will give deprecation warnings, and in 3.2 we will simply overwrite the default scope when you call the macro multiple times.

Deprecated support for passing hashes and relations to default_scope, in favour of defining a 'default_scope' class method in the model. See the CHANGELOG for more details.

while declaring default_scope

Also added test for unscoped using block style with four different
combinations
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

order that is declared first has highest priority in all cases.

Here are some examples.

Car.order('name desc').find(:first, :order => 'id').name

Car.named_scope_with_order.named_scope_with_another_order

Car.order('id DESC').scoping do
  Car.find(:first, :order => 'id asc')
end

No special treatment to with_scope or scoping.

Also note that if default_scope declares an order then the order
declared in default_scope has the highest priority unless
with_exclusive_scope is used.
Signed-off-by: NSantiago Pastorino <santiago@wyeworks.com>

While creating a new record using has_many create method default scope of child should be respected.

author.posts.create should take into account default_scope
defined on post.

[#3939: state:resolved]
Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

Signed-off-by: NJosé Valim <jose.valim@gmail.com>

[#4984 state:resolved]
Signed-off-by: NJosé Valim <jose.valim@gmail.com>