| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Before this commit, returning `false` in an ActiveRecord `before_` callback
such as `before_create` would halt the callback chain.
After this commit, the behavior is deprecated: will still work until
the next release of Rails but will also display a deprecation warning.
The preferred way to halt a callback chain is to explicitly `throw(:abort)`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
|
|
|
|
|
|
| |
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)`
|
| |
|
|
|
|
| |
Conflicts:
activerecord/test/models/bulb.rb
activerecord/test/schema/schema.rb
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
It doesn't serve much purpose now that ActiveRecord::Base.all returns a
Relation.
The code is moved to active_record_deprecated_finders.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
| |
before_initialize callback of the record runs. Fixes #1842.
|
| |
|
|
|
|
|
| |
The build_association method was added as an API for plugins
to hook into in 1398db0. This commit restores this API and the
ability to override class.new to return a subclass based on
a virtual attribute in the attributes hash.
|
| |
|
|
| |
attributes when copying, rather than using the assignment method
|
| |
|
|
| |
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.
|
| |
|
|
| |
this can affect validations/callbacks/etc inside the record itself [#6252 state:resolved]
|
|
|
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>
|
