aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/models/car.rb
Commit message (Collapse)AuthorAgeFilesLines
* Fixed `where` for polymorphic associations when passed an array containing ↵Philippe Huibonhoa2016-02-161-0/+2
| | | | | | | | | | | | | | | | | different types. When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array. PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)]) # => SELECT "price_estimates".* FROM "price_estimates" WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2)) This is fixed to properly look for any records matching both type and id: PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)]) # => SELECT "price_estimates".* FROM "price_estimates" WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1) OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))
* 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.
* Improve consistency of counter caches updating in memorySean Griffin2015-01-261-1/+1
| | | | | | | | | | | | | | | | | 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]
* Make AR::Base#touch fire the after_commit and after_rollback callbacksHarry Brundage2014-01-161-1/+0
|
* Raise `RecordNotDestroyed` when children can't be replacedBrian Thomas Storti2013-11-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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`.
* Fix ActiveRecord::Relation#unscopeJon Leighton2013-11-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 94924dc32baf78f13e289172534c2e71c9c8cade, 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.
* More unused associations in AR test modelsAkira Matsuda2013-09-101-3/+0
|
* Revert "Merge branch 'master' of github.com:rails/docrails"Vijay Dev2013-08-171-0/+3
| | | | | | | This reverts commit 70d6e16fbad75b89dd1798ed697e7732b8606fa3, reversing changes made to ea4db3bc078fb3093ecdddffdf4f2f4ff3e1e8f9. Seems to be a code merge done by mistake.
* More unused associations in AR test modelsAkira Matsuda2013-07-251-3/+0
|
* Do not invoke callbacks when delete_all is calledNeeraj Singh2013-06-301-0/+1
| | | | | | | | | | | 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)`
* Convert association macros to the new syntaxJon Leighton2012-07-201-3/+3
|
* remove deprecated scope stuffJon Leighton2012-04-261-1/+0
|
* Deprecate eager-evaluated scopes.Jon Leighton2012-03-211-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Test polymorphic record with optimistic locking and counter cache should be ↵Dmitry Polushkin2011-09-091-1/+1
| | | | destoyed without catching the ActiveRecord::StaleObjectError.
* Ensure we are not comparing a string with a symbol in ↵Jon Leighton2011-09-061-1/+1
| | | | HasManyAssociation#inverse_updates_counter_cache?. Fixes #2755, where a counter cache could be decremented twice as far as it was supposed to be.
* Don't use mass-assignment protection when setting foreign keys or ↵Jon Leighton2011-05-121-0/+3
| | | | association conditions on singular associations. Fixes #481 (again).
* 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-6/+2
| | | | 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-2/+7
| | | | favour of defining a 'default_scope' class method in the model. See the CHANGELOG for more details.
* expanding the test to include both type of order declarationNeeraj Singh2010-09-181-2/+9
| | | | | | | | | 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 should always be concatenated.Neeraj Singh2010-09-051-0/+5
| | | | | | | | | | | | | | | | | | | | | | 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>
* While creating a new record using has_many create method default scope of ↵Neeraj Singh2010-08-191-0/+1
| | | | | | | | | | | 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>
* Ensure we can nest include calls [#5285 state:resolved]Neeraj Singh2010-08-121-0/+5
| | | | Signed-off-by: José Valim <jose.valim@gmail.com>
* reset_counter should work with non-traditional belongs_to and polymorphic ↵Neeraj Singh2010-07-081-0/+4
belongs_to [#4984 state:resolved] Signed-off-by: José Valim <jose.valim@gmail.com>