When we made sure that the counter gets updated in memory, we only did
it on the has many side. The has many side only does the update if the
belongs to cannot. The belongs to side was updated to update the counter
cache (if it is able). This means that we need to check if the
belongs_to is able to update in memory on the has_many side.
We also found an inconsistency where the reflection names were used to
grab the association which should update the counter cache. Since
reflection names are now strings, this means it was using a different
instance than the one which would have the inverse instance set.
Fixes#18689
[Sean Griffin & anthonynavarre]
Fixes#12812
Raise `ActiveRecord::RecordNotDestroyed` when a child marked with
`dependent: destroy` can't be destroyed.
The following code:
```ruby
class Post < ActiveRecord::Base
has_many :comments, dependent: :destroy
end
class Comment < ActiveRecord::Base
before_destroy do
return false
end
end
post = Post.create!(comments: [Comment.create!])
post.comments = [Comment.create!]
````
would result in a `post` with two `comments`.
With this commit, the same code would raise a `RecordNotDestroyed`
exception, keeping the `post` with the same `comment`.
I'm pretty confused about the addition of this method. The documentation
says that it was intended to allow the removal of values from the
default scope (in contrast to #except). However it behaves exactly the
same as except: https://gist.github.com/jonleighton/7537008 (other than
having a slightly enhanced syntax).
The removal of the default scope is allowed by
94924dc32b, which was not a change we
could make until 4.1 due to the need to deprecate things. However after
that change #unscope still gives us nothing that #except doesn't already
give us.
However there *is* a desire to be able to unscope stuff in a way that
persists across merges, which would allow associations to be defined
which unscope stuff from the default scope of the associated model. E.g.
has_many :comments, -> { unscope where: :trashed }
So that's what this change implements. I've also corrected the
documentation. I removed the guide references to #except as I think
unscope really supercedes #except now.
While we're here, there's also a potential desire to be able to write
this:
has_many :comments, -> { unscoped }
However, it doesn't make sense and would not be straightforward to
implement. While with #unscope we're specifying exactly what we want to
be removed from the relation, with "unscoped" we're just saying that we
want it to not have some things which were added earlier on by the
default scope. However in the case of an association, we surely don't
want *all* conditions to be removed, otherwise the above would just
become "SELECT * FROM comments" with no foreign key constraint.
To make the above work, we'd have to somehow tag the relation values
which get added when evaluating the default scope in order to
differentiate them from other relation values. Which is way too much
complexity and therefore not worth it when most use cases can be
satisfied with unscope.
Closes#10643, #11061.
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
while declaring default_scope
Also added test for unscoped using block style with four different
combinations
Signed-off-by: José 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: Santiago Pastorino <santiago@wyeworks.com>
