- 16 1月, 2015 1 次提交
-
-
由 brainopia 提交于
after_commit callbacks run after committing a transaction whose parent is not `joinable?`: un-nested transactions, transactions within test cases, and transactions in `console --sandbox`.
-
- 31 12月, 2014 1 次提交
-
-
由 brainopia 提交于
-
- 09 12月, 2014 1 次提交
-
-
To be possible to use a custom column name to save/read the polymorphic associated type in a has_many or has_one polymorphic association, now users can use the option :foreign_type to inform in what column the associated object type will be saved.
-
- 29 11月, 2014 1 次提交
-
-
由 Erik Michaels-Ober 提交于
-
- 28 11月, 2014 1 次提交
-
-
由 Yuki Nishijima 提交于
Since 3e30c5d4, it started ignoring the given error message. This commit changes the behavior of AR::RecordNotSaved#initialize so that it no longer loses the given error message.
-
- 26 11月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
The records weren't being replaced since equality in Active Record is defined in terms of `id` only. It is reasonable to expect that the references would be replaced in memory, even if no queries are actually executed. This change did not appear to affect any other parts of the code base. I chose not to execute callbacks since we're not actually modifying the association in a way that will be persisted. Fixes #17730
-
- 14 11月, 2014 1 次提交
-
-
由 Arun Agrawal 提交于
`Computer` class needs to be require See #17217 for more details
-
- 08 11月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
if you specify a default scope on a model, it will break caching. We cannot predict what will happen inside the scope, so play it safe for now. fixes #17495
-
- 23 10月, 2014 1 次提交
-
-
由 Byron Bischoff 提交于
-
- 03 10月, 2014 1 次提交
-
-
由 Ben Woosley 提交于
Fix that a collection proxy could be cached before the save of the owner, resulting in an invalid proxy lacking the owner’s id. Absent this fix calls like: owner.association.update_all to behave unexpectedly because they try to act on association objects where owner_id is null. more evidence here: https://gist.github.com/Empact/5865555 ``` Active Record 3.2.13 -- create_table(:firms, {:force=>true}) -> 0.1371s -- create_table(:clients, {:force=>true}) -> 0.0005s 1 clients. 1 expected. 1 clients updated. 1 expected. ``` ``` Active Record 4.0.0 -- create_table(:firms, {:force=>true}) -> 0.1606s -- create_table(:clients, {:force=>true}) -> 0.0004s 1 clients. 1 expected. 0 clients updated. 1 expected. ```
-
- 06 9月, 2014 1 次提交
-
-
由 Rafael Mendonça França 提交于
Callback order in Active Record objects are important. Users should not define callbacks before the association definition or surprising behaviours like the described at #3798 will happen. This callback order dependency is documented at https://github.com/rails/rails/blob/31bfcdc77ca0d8cec9b5fe513bdc6f05814dd4f1/activerecord/lib/active_record/associations.rb#L1222-1227. This reverts #15728. Fixes #16620.
-
- 28 8月, 2014 1 次提交
-
-
由 Akira Matsuda 提交于
-
- 26 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Reliant on https://github.com/rails/rails/pull/15747 but pulled to a separate PR to reduce noise. `has_many :through` associations have the undocumented behavior of automatically detecting counter caches. However, the way in which it does so is inconsistent with counter caches everywhere else, and doesn't actually work consistently. As with normal `has_many` associations, the user should specify the counter cache on the `belongs_to`, if they'd like it updated.
-
- 16 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Before, calling `size` would only work if it skipped the cache, and would return a different result from the cache, but only if: - The association was previously loaded - Or you called size previously - But only if the size was 0 when you called it This ensures that the counter is appropriately updated in memory.
-
- 10 6月, 2014 1 次提交
-
-
由 David Verhasselt 提交于
-
- 10 5月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 04 5月, 2014 2 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
由 Carlos Antonio da Silva 提交于
Only care about its truthiness rather than asserting specific true/false values. If we need to check for the return value in particular, there will be a test for that.
-
- 03 5月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
bind parameters we not being propogated to simple subquery calculation calls. This fixes it
-
- 01 5月, 2014 1 次提交
-
-
由 Eric Chahin 提交于
associations were not being saved. Fixes #13854. [Eric Chahin, Aaron Nelson, & Kevin Casey]
-
- 29 4月, 2014 1 次提交
-
-
由 eileencodes 提交于
Test checks that SQL is the same for a loaded vs not loaded association (category.categorizations, category.categorization.delete_all vs category.cartegroization.delete_al). This was fixed for delete_all dependency but was not fixed for no (:nullify, or nil) dependency).
-
- 04 4月, 2014 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 03 4月, 2014 1 次提交
-
-
由 Lauro Caetano 提交于
It was causing error when using `with_options` passing a lambda as its last argument. class User < ActiveRecord::Base with_options dependent: :destroy do |assoc| assoc.has_many :profiles, -> { where(active: true) } end end It was happening because the `option_merger` was taking the last argument and checking if it was a Hash. This breaks the HasMany usage, because its last argument can be a Hash or a Proc. As the behavior described in this test: https://github.com/rails/rails/blob/master/activesupport/test/option_merger_test.rb#L69 the method will only accept the lambda, this way it will keep the expected behavior. See 9eaa0a34
-
- 01 4月, 2014 1 次提交
-
-
由 eileencodes 提交于
delete_all sql if an association is not loaded should behave the same as if the association is loaded. This test ensures the SQL statements are exactly the same.
-
- 01 3月, 2014 1 次提交
-
-
由 Arthur Neves 提交于
When replacing a has_many association with the same one, there is no need to do a round-trip to the db to create/and drop a new transaction. [fixes #14220]
-
- 21 2月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
This reverts commit 5e3d466d.
-
- 09 2月, 2014 1 次提交
-
-
由 Kevin Casey 提交于
-
- 31 1月, 2014 1 次提交
-
-
由 Lauro Caetano 提交于
Dangerous association names conflicts include instance or class methods already defined by `ActiveRecord::Base`.
-
- 28 1月, 2014 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
- 22 1月, 2014 1 次提交
-
-
由 Jason Meller 提交于
This commit fixes two regressions introduced in cafe31a0 where newly created finder methods #second, #third, #forth, and #fifth caused a NoMethodError error on reload associations and where we were pulling the wrong element out of cached associations. Examples: some_book.authors.reload.second # Before # => NoMethodError: undefined method 'first' for nil:NilClass # After # => #<Author id: 2, name: "Sally Second", ...> some_book.first.authors.first some_book.first.authors.second # Before # => #<Author id: 1, name: "Freddy First", ...> # => #<Author id: 1, name: "Freddy First", ...> # After # => #<Author id: 1, name: "Freddy First", ...> # => #<Author id: 2, name: "Sally Second", ...> Fixes #13783.
-
- 19 12月, 2013 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
Change most tests to make use of assert_raise returning the raised exception rather than relying on a combination of flunk + rescue to check for exception types/messages.
-
- 26 11月, 2013 3 次提交
-
-
由 heruku 提交于
-
由 Brian Thomas Storti 提交于
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`.
-
由 Vipul A M 提交于
-
- 21 11月, 2013 1 次提交
-
-
由 Jon Leighton 提交于
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 94924dc3, 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.
-
- 17 11月, 2013 1 次提交
-
-
由 Edo Balvers 提交于
-
- 02 11月, 2013 2 次提交
-
-
由 Rafael Mendonça França 提交于
was using nullify strategy This caused a regression in applications trying to upgrade. Also if the user set the dependent option as destroy he expects to get the records removed from the database.
-
由 Rafael Mendonça França 提交于
-
- 29 10月, 2013 1 次提交
-
-
由 David Heinemeier Hansson 提交于
-
- 28 9月, 2013 1 次提交
-
-
由 Paul Nikitochkin 提交于
In order to build associated records for owners which has not been saved need to get where values to use as default attributes. But for new record owner uses `ActiveRecord::NullRelation` which override `where_values_hash` to return empty hash stub. `where_values_hash` is not used to invoke any sql query, but good to build others chains (even will be never executed) like: ```ruby post = Post.new admin_comment = post.admin_comments.build assert_equal 'Admin', admin_comment.author ``` Closes #11376, #11676, #11675
-