aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/models/bulb.rb
Commit message (Collapse)AuthorAgeFilesLines
* Don't skip in-memory insertion of associations when loaded in validateSean Griffin2016-09-291-6/+0
| | | | | | | | | | | | | | | | This was caused by 6d0d83a33f59d9415685852cf77818c41e2e2700. While the bug it's trying to fix is handled if the association is loaded in an after_(create|save) callback, it doesn't handle any cases that load the association before the persistence takes place (validation, or before_* filters). Instead of caring about the timing of persistence, we can just ensure that we're not double adding the record instead. The test from that commit actually broke, but it was not because the bug has been re-introduced. It was because `Bulb` in our test suite is doing funky things that look like STI but isn't STI, so equality comparison didn't happen as the loaded model was of a different class. Fixes #26661.
* modernizes hash syntax in activerecordXavier Noria2016-08-061-2/+2
|
* applies new string literal convention in activerecord/testXavier Noria2016-08-061-2/+2
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Bugfix collection association #create method …Bogdan Gusiev2015-11-231-0/+6
| | | | | When same association is loaded in the model creation callback The new object is inserted into association twice
* Except keys of `build_record`'s argument from `create_scope` in ↵yui-knk2015-11-161-0/+1
| | | | | | | | | | | | | | initialize_attributes If argument of `build_record` has key and value which is same as default value of database, we should also except the key from `create_scope` in `initialize_attributes`. Because at first `build_record` initialize record object with argument of `build_record`, then assign attributes derived from Association's scope. In this case `record.changed` does not include the key, which value is same as default value of database, so we should add the key to except list. Fix #21893.
* Deprecate `false` as the way to halt AR callbacksclaudiob2015-01-021-1/+1
| | | | | | | | | | 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)`.
* 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>