| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This reverts commit 70d6e16fbad75b89dd1798ed697e7732b8606fa3, reversing
changes made to ea4db3bc078fb3093ecdddffdf4f2f4ff3e1e8f9.
Seems to be a code merge done by mistake.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
destoyed without catching the ActiveRecord::StaleObjectError.
|
|
|
|
| |
HasManyAssociation#inverse_updates_counter_cache?. Fixes #2755, where a counter cache could be decremented twice as far as it was supposed to be.
|
|
|
|
| |
association conditions on singular associations. Fixes #481 (again).
|
|
|
|
| |
be assigned without mass-assignment protection when a record is built on the association.
|
|
|
|
| |
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.
|
|
|
|
| |
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: 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>
|
|
|
|
|
|
|
|
|
|
|
| |
child should be respected.
author.posts.create should take into account default_scope
defined on post.
[#3939: state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
|
belongs_to
[#4984 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|