| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
Since #31405, using `#increment!` with touch option instead of `#touch`
to touch belongs_to association if counter cache is enabled. It caused
the regression since `#increment!` won't invoke after_touch callbacks
even if touch option is given.
To fix the regression, make `#increment!` invokes after_touch callbacks
if touch option is given.
Fixes #31559.
Fixes #32408.
|
|
|
|
|
|
|
|
|
|
|
| |
On belongs_to with `touch: true` association, unassigned object is
caused touching, but assigned object is not touched.
And also, if primary key is customized, it will touch against the wrong
target looked up by the customized key as primary key.
This change ensures correctly touching consistently between assigning
and unassigning.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
counter
If belongs_to primary key is customized, the callback will update
counters against the wrong target looked up by the customized key as
primary key.
We need to convert the customized key into an object that can be
referred to as primary key.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since #31575, `BelongsToAssociation#target=` replaces owner record's
foreign key to fix an inverse association bug.
But the method is not only used for inverse association but also used
for eager loading/preloading, it caused some public behavior changes
(#32338, #32375).
To avoid any side-effect in loading associations, I reverted the
overriding `#target=`, then introduced `#inversed_from` to replace
foreign key in `set_inverse_instance`.
Closes #32375.
|
|
|
|
| |
Follow up of #32605.
|
|
|
|
| |
If a 'has one' object is created from a new record, an ActiveRecord::RecordNotSaved error is raised but this behavior was also applied to the reverse scenario.
|
|\
| |
| | |
Use MethodCallAssertions instead of mocha expects
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Currently `ids_reader` doesn't respect dirty target when the target is
not loaded yet unlike `collection.size`. I believe the inconsistency is
a bug, fixes the `ids_reader` to behave consistently regardless of
whether target is loaded or not.
|
|\ \
| | |
| | | |
Loaded associations should not run a new query when size is called
|
| |/
| |
| |
| |
| |
| |
| | |
Already loaded associations were running an extra query when `size` was called on the association.
This fix ensures that an extra query is no longer run.
Update tests to use proper methods
|
|/
|
|
|
| |
This is to ensure that the behavior has not changed before and after
#31575.
|
|
|
|
| |
Follow up of #32514.
|
|\
| |
| |
| |
| | |
samdec/multiple-has-one-through-associations-build-bug
Fix .new with multiple through associations
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a bug with building an object that has multiple
`has_many :through` associations through the same object.
Previously, when building the object via .new, the intermediate
object would be created instead of just being built.
Here's an example:
Given a GameBoard, that has_one Owner and Collection through Game.
The following line would cause a game object to be created in the
database.
GameBoard.new(owner: some_owner, collection: some_collection)
Whereas, if passing only one of those associations into `.new` would
cause the Game object to be built and not created in the database.
Now the above code will only build the Game object, and not save it.
|
| | |
|
| | |
|
|/
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
|
|
| |
73e7aab behaved as expected on codeship, failing the build with
exactly these RuboCop violations. Hopefully `rubocop -a` will
have been enough to get a passing build!
|
|
|
|
| |
https://travis-ci.org/rails/rails/jobs/360109429
|
|
|
|
|
|
|
|
|
| |
When a belongs to association's target is set, its foreign key is now
updated to match the new target. This is the correct behaviour when a
new record is assigned, but not when the existing record is preloaded.
As long as we mark the association as loaded, we can skip setting the
target when the record is missing and avoid clobbering the foreign key.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a class has a belongs_to or has_one relationship with dependent: :destroy
option enabled, objects of this class should not be deleted if it's dependents
cannot be deleted.
Example:
class Parent
has_one :child, dependent: :destroy
end
class Child
belongs_to :parent, inverse_of: :child
before_destroy { throw :abort }
end
c = Child.create
p = Parent.create(child: c)
p.destroy
p.destroyed? # expected: false; actual: true;
Fixes #32022
|
|
|
|
|
|
|
|
|
|
| |
This reverts ignoring polymorphic error introduced at 02da8ae.
What the ignoring want to solve was caused by force eager loading
regardless of whether it is necessary, but it has been fixed by #29043.
The ignoring is now only causing a mismatch of `exists?` behavior with
`to_a`, `count`, etc. It should behave consistently.
|
|
|
|
|
|
|
| |
This is an alternative of #29722, and follow up of #32048.
This does not change the current behavior, but makes it easier to modify
all polymorphic names consistently.
|
|
|
|
|
|
|
|
| |
Since #31895, build of 2.5 and AR combination failed.
https://travis-ci.org/rails/rails/jobs/346064349#L1638
It seems to be the reason that model is not loading properly, so I added
require. But I'm not sure if this is correct
|
|\
| |
| |
| |
| | |
kamipo/do_not_attempt_to_find_inverse_of_polymorphic
Make `reflection.klass` raise if `polymorphic?` not to be misused
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is an alternative of #31877 to fix #31876 caused by #28808.
This issue was caused by a combination of several loose implementation.
* finding automatic inverse association of polymorphic without context (caused by #28808)
* returning `klass` even if `polymorphic?` (exists before #28808)
* loose verification by `valid_inverse_reflection?` (exists before #28808)
This makes `klass` raise if `polymorphic?` not to be misused.
This issue will not happen unless polymorphic `klass` is misused.
Fixes #31876.
Closes #31877.
|
|/
|
|
|
|
|
|
|
|
|
| |
This is an alternative of #29722, and revert of #29601 and a1fcbd9.
Currently, association creation and normal association finding doesn't
respect `store_full_sti_class`. But eager loading and preloading respect
the setting. This means that if set `store_full_sti_class = false`
(`true` by default), eager loading and preloading can not find
created polymorphic records.
Association creation and finding should work consistently.
|
|
|
|
|
|
|
|
|
|
| |
3acc5d6 was changed the order of scope evaluation from through scope to
the association's own scope to be prioritized over the through scope.
But the sorting order will be prioritized that is evaluated first. It is
unintentional effect, association scope's sorting order should be
prioritized as well.
Fixes #32008.
|
|
|
|
| |
Closes #31998
|
|\
| |
| |
| | |
Fix marshaling of models with `has_many :through` associations
|
|/ |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #31762.
|
|
|
|
|
|
| |
When removing a record from a has many through association, the counter
cache was being updated even if the through record halted the callback
chain and prevented itself from being destroyed.
|
|\
| |
| |
| | |
When deleting through records, take into account association conditions
|
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #18424.
When deleting through records, it didn't take into account the
conditions that may have been affecting join model table, but was
defined in association definition.
|
| |
| |
| |
| | |
Need reloading when through record has replaced.
|
|\ \
| | |
| | |
| | |
| | |
| | | |
zoltankiss/allow-nested-has-many-associations-on-unpersisted-parent-instances
fix nested `has many :through` associations on unpersisted parent instances
|
| | |
| | |
| | |
| | | |
Fixes: #16313
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently reflections keeps the order when first added even if when
redefining association. As a result of the order, redefining through
association which use newly added association will raise
`HasManyThroughOrderError`. We need to redefine reflection order as well
when redefining association.
Fixes #31068.
|
|\ \ \
| | | |
| | | |
| | | | |
Use `count(:all)` in HasManyAssociation#count_records
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Problem: Calling `count` on an association can cause invalid SQL queries
to be created where the `SELECT COUNT(a, b, c)` function receives
multiple columns. This will cause a `StatementInvalid` exception later
on.
Solution: Use `count(:all)`, which generates a `SELECT COUNT(*)...`
query independently of the association.
This also includes a test case that, before the fix, broke.
|
| | | |
| | | |
| | | |
| | | | |
This is a regression test for #27864.
|