aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/models/bulb.rb
Commit message (Collapse)AuthorAgeFilesLines
* Raise `RecordNotDestroyed` when children can't be replacedBrian Thomas Storti2013-11-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* Do not invoke callbacks when delete_all is calledNeeraj Singh2013-06-301-0/+6
| | | | | | | | | | | 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)`
* Make sure the tests pass in the case closer to described in #8195Rafael Mendonça França2012-12-101-1/+1
| | | | | | Conflicts: activerecord/test/models/bulb.rb activerecord/test/schema/schema.rb
* Remove mass_assignment_options from ActiveRecordGuillermo Iguaran2012-09-161-3/+3
|
* Remove mass assignment security from ActiveRecordGuillermo Iguaran2012-09-161-2/+0
|
* Deprecate ActiveRecord::Base.scoped.Jon Leighton2012-07-271-1/+1
| | | | | | | It doesn't serve much purpose now that ActiveRecord::Base.all returns a Relation. The code is moved to active_record_deprecated_finders.
* Deprecate eager-evaluated scopes.Jon Leighton2012-03-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* use existing model for testing Base.create with #after_initializeGabriel Horner2011-07-241-0/+5
|
* Assign the association attributes to the associated record before the ↵Jon Leighton2011-06-301-2/+7
| | | | before_initialize callback of the record runs. Fixes #1842.
* Pass the attribute and option hashes to build_associationAndrew White2011-05-171-0/+13
| | | | | | | 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.
* CollectionAssociation#merge_target_lists should write to the underlying ↵Jon Leighton2011-05-141-0/+4
| | | | attributes when copying, rather than using the assignment method
* Add test to specify that attributes from an association's conditions should ↵Jon Leighton2011-05-101-0/+2
| | | | 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 ↵Jon Leighton2011-04-181-4/+1
| | | | 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 ↵Jon Leighton2011-04-121-6/+7
| | | | favour of defining a 'default_scope' class method in the model. See the CHANGELOG for more details.
* We shouldn't be using scoped.scoping { ... } to build associated records, as ↵Jon Leighton2011-01-301-2/+9
| | | | this can affect validations/callbacks/etc inside the record itself [#6252 state:resolved]
* While creating a new record using has_many create method default scope of ↵Neeraj Singh2010-08-191-0/+7
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>