| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
We deprecate the support for passing an argument to force reload in
6eae366d0d2e5d5211eeaf955f56bd1dc6836758. That led to several
deprecation warning when running Active Record test suite.
This commit silence the warnings by properly calling `#reload` on the
association proxy or on the association object instead. However, there
are several places that `ActiveSupport::Deprecation.silence` are used as
those tests actually tests the force reload functionality and will be
removed once `master` is targeted next minor release (5.1).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The changes introduced to through associations in c80487eb were quite
interesting. Changing `relation.merge!(scope)` to `relation =
relation.merge(scope)` should in theory never cause any changes in
behavior. The subtle breakage led to a surprising conclusion.
The old code wasn't doing anything! Since `merge!` calls
`instance_exec` when given a proc, and most scopes will look something
like `has_many :foos, -> { where(foo: :bar) }`, if we're not capturing
the return value, it's a no-op. However, removing the `merge` causes
`unscope` to break.
While we're merging in the rest of the chain elsewhere, we were never
merging in `unscope` values, causing a breakage on associations where a
default scope was being unscoped in an association scope (yuk!). This is
subtly related to #20722, since it appears we were previously relying on
this mutability.
Fixes #20721.
Fixes #20727.
|
|
|
|
|
|
|
|
|
| |
See #9683 for the reasons we switched to `distinct`.
Here is the discussion that triggered the actual deprecation #20198.
`uniq`, `uniq!` and `uniq_value` are still around.
They will be removed in the next minor release after Rails 5.
|
|
|
|
|
|
|
|
|
| |
The old `test_create_bang_returns_falsy_when_join_record_has_errors` had
a missleading name and was a duplicate of
`test_save_should_not_raise_exception_when_join_record_has_errors`.
Since it had an assertion on the return value I renamed it accordingly
and got rid of the duplicate test.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
Various behaviors needed by associations (such as creating the through
record) are lost when `where` is called, since we stop having a
`CollectionProxy` and start having an `AssociationRelation` which does
not contain this behavior. I *think* we should be able to rm
`AssociationRelation`, but we have tests saying the changes required to
do that would be bad (Without saying why. Of course. >_>)
Fixes #19073.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Add setting of FK for throgh associations while building
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/cases/associations/has_many_through_associations_test.rb
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
`Computer` class needs to be require
See #17217 for more details
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Don't save through records twice
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/cases/associations/has_many_through_associations_test.rb
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the through record gets created in an `after_create` hook that is
defined before the association is defined (therefore after its
`after_create` hook) get saved twice. This ensures that the through
records are created only once, regardless of the order of the hooks.
|
|/ / |
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
member = Member.new(club: Club.new)
member.save!
Before:
member.current_membership.club_id # => nil
After:
member.current_membership.club_id # => club's id
|
|
|
|
|
|
| |
Since clear shouldn't fire callbacks the order doesn't
matter since it was never updated. Remove the portion
of this test that tests for order after clear.
|
|
|
|
| |
This file is using this pattern already
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Properly handle scoping with has_many :through. Fixes #14537.
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/cases/associations/has_many_through_associations_test.rb
|
| | |
|
|\ \
| |/
|/|
| |
| |
| |
| | |
Fix insertion of records for hmt association with scope
Conflicts:
activerecord/CHANGELOG.md
|
| | |
|
|/
|
|
| |
[related #14116]
|
|
|
|
|
| |
when destroying a record on a has_many :through association.
:destroy method has own counter_cache callbacks.
|
| |
|
|
|
|
| |
Fixes: #12242, #9517, #10240
|
|
|
|
|
|
| |
original commit 8998441967a8cfc6e4302c29664ab9d0acd77704
Reverted here ec8ef1e1055c4e1598da13f49d30261f07f4a9b4
|
|
|
|
| |
side of a hm:t association along with preloading.
|
|
|
|
| |
conditionals from the individual preloaded classes
|
|
|
|
| |
and possibly different rules for finding those objects
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
actionview/README.rdoc
activerecord/lib/active_record/migration.rb
guides/source/development_dependencies_install.md
guides/source/getting_started.md
|
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 70d6e16fbad75b89dd1798ed697e7732b8606fa3, reversing
changes made to ea4db3bc078fb3093ecdddffdf4f2f4ff3e1e8f9.
Seems to be a code merge done by mistake.
|
|/ |
|
| |
|
|
|
|
|
|
| |
association proxy
Closes #11248.
|
|
|
|
|
|
|
|
|
|
|
| |
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)`
|
|
|
|
| |
fixes #10016
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This caused a bug with the new associations implementation, because now
association conditions are represented as Arel nodes internally right up
to when the whole thing gets turned to SQL.
In Rails 3.2, association conditions get turned to raw SQL early on,
which prevents Relation#merge from interfering.
The current implementation was buggy when a default_scope existed on the
target model, since we would basically end up doing:
default_scope.merge(association_scope)
If default_scope contained a where(foo: 'a') and association_scope
contained a where(foo: 'b').where(foo: 'c') then the merger would see
that the same column is representated on both sides of the merge and
collapse the wheres to all but the last: where(foo: 'c')
Now, the RHS of the merge is left alone.
Fixes #8990
|