| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| | |
`Computer` class needs to be require
See #17217 for more details
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Empact/association-bind-values-not-updated-on-save
Fix that a collection proxy could be cached before the save of the owner, resulting in an invalid proxy lacking the owner’s id
Conflicts:
activerecord/CHANGELOG.md
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
```
|
| | |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
| |
preloading, fixes #11036
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |\
| |
| | |
If a counter_cache exists, use it for #empty?
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |\
| |
| |
| | |
Fixed custom validation context bug for child associations
|
| | |
| |
| |
| |
| |
| |
| |
| | |
associations were not being saved.
Fixes #13854.
[Eric Chahin, Aaron Nelson, & Kevin Casey]
|
| |/
|
|
|
| |
bind parameters we not being propogated to simple subquery calculation
calls. This fixes it
|
| |
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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]
|
| |
|
|
| |
This reverts commit 5e3d466d52fa4e9a42c3a1f8773a7c31da875e48.
|
| | |
|
| |
|
|
|
| |
Dangerous association names conflicts include instance or class
methods already defined by `ActiveRecord::Base`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes two regressions introduced in cafe31a078 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.
|
| |\
| |
| |
| |
| | |
derikson/collection_proxy_select_with_multiple_args
Change CollectionProxy#select to take the same arguments as ActiveRecord::select
|
| | |
| |
| |
| |
| |
| | |
arguments.
This makes the arguments the same as ActiveRecord::QueryMethods::select.
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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`.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
automatically
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| | |
broken
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| | |
.find([1]) should return an Array of entries, even when a invese object is in memory already
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When first or last is called with an integer on an unloaded association,
the entire collection is loaded. This differs surprisingly from the
behavior of Relation#first/last, which translate the call into a limit
query. For large collections this can make a big difference in
performance.
Change CollectionAssociation#fetch_first_or_last_using_find? to make
this kind of call delegate to Relation.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
order on the old ones
The previous behavior added a major backward incompatibility since it
impossible to have a upgrade path without major changes on the
application code.
We are taking the most conservative path to be consistent with the idea
of having a smoother upgrade on Rails 4.
We are reverting the behavior for what was in Rails 3.x and,
if needed, we will implement a new API to prepend the order clauses in
Rails 4.1.
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
neerajdotname/delete_all_should_not_call_callbacks
Do not invoke callbacks when delete_all is called
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)`
|
