| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to simplify the association API, as you can call `reload` on the
association proxy or the parent object to get the same result.
For collection association, you can call `#reload` on association proxy
to force a reload:
@user.posts.reload # Instead of @user.posts(true)
For singular association, you can call `#reload` on the parent object to
clear its association cache then call the association method:
@user.reload.profile # Instead of @user.profile(true)
Passing a truthy argument to force association to reload will be removed
in Rails 5.1.
|
| |
|
|
|
|
|
| |
When `AR::Base.save!` or `AR::Base.destroy!` is called and an exception
is raised, the exception doesn't have any error message or has a weird
message like `#<FailedBulb:0x0000000907b4b8>`. Give a better message so
we can easily understand why it's failing to save/destroy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
In 1f006c an option was added called :class to allow passing anonymous
classes to association definitions. Since using :class instead of
:class_name is a fairly common typo even amongst experienced developers
this can result in hard to debug errors arising in raise_on_type_mismatch?
To fix this we're renaming the option from :class to :anonymous_class as
that is a more correct description of what the option is for. Since this
was an internal, undocumented option there is no need for a deprecation.
Fixes #19659
|
| |
|
|
| |
When replacing a has_many association with the same one, there is nothing to do with database but a setter method should still return the substituted value for backward compatibility.
|
| |
|
|
|
|
|
|
|
|
| |
present from the start.
When a new record has the necessary information prior to save, we can
avoid busting the cache.
We could simply clear the @proxy on #reset or #reset_scope, but that
would clear the cache more often than necessary.
|
| | |
|
| |\
| |
| |
| |
| | |
rebyn/fix/17161-remove-objs-from-has_many-updates-fields
Add specs for adding-to/clear has_many collections’s behavior on `updated_at`
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are behaviors mentioned in #17161 that:
1. are not documented properly, and
2. don't have specs
This commit addresses the spec absence. For has_many collections,
1. addition (<<) should update the associated object's updated_at (if any)
2. .clear, depending on options[:dependent], calls delete_all, destroy_all, or nullifies the associated object(s)' foreign key.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Use SQL COUNT and LIMIT 1 queries for none? and one? methods if no block or limit is given,
instead of loading the entire collection to memory. The any? and many? methods already
follow this behavior.
[Eugene Gilburg & Rafael Mendonça França]
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The only place it was accessed was in tests. Many of them have another
way that they can test their behavior, that doesn't involve reaching
into internals as far as they did. `AssociationScopeTest` is testing a
situation where the where clause would have one bind param per
predicate, so it can just ignore the predicates entirely. The where
chain test was primarly duplicating the logic tested on `WhereClause`
directly, so I instead just make sure it calls the appropriate method
which is fully tested in isolation.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
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`.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Since 3e30c5d, 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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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`.
|
