aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/associations
Commit message (Collapse)AuthorAgeFilesLines
* Don't use `target=`Rafael Mendonça França2018-06-111-1/+1
| | | | | It mark the association as loaded and this can cause the object to be in an stale state.
* Use `-=` to change the update the collection on the associationRafael Mendonça França2018-06-111-1/+1
| | | | | This also mark the association as loaded given we changed it in memory and avoid the next access to the reader to make a query to the databse.
* Fix alias confliction when joining same table on has many through with ↵Ryuta Kamizono2018-06-111-0/+4
| | | | | | | | | | left_joins This regression was caused by #30995 due to `Hash#fetch` won't invoke default proc. Just revert the change since #30995 is completely fixed by e9c1653. Fixes #33048.
* Fix `collection.create` to could be rolled back by `after_save`Ryuta Kamizono2018-06-071-0/+11
| | | | | | | | | | | In `_create_record`, explicit `transaction` block requires rollback handling manually when `insert_record` is failed. We need to handle it in `_create_record`, not in `insert_record`, since our test cases expect a record added to target and returned even if `insert_record` is failed, Closes #31488.
* Initialization block is a part of `build_record`Ryuta Kamizono2018-06-041-0/+12
| | | | Should be done before `before_add` callbacks.
* Fix that association's after_touch is not called with counter cacheRyuta Kamizono2018-05-271-0/+17
| | | | | | | | | | | | 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.
* Fix inconsistent touching behavior between assigning and unassigningRyuta Kamizono2018-05-271-0/+25
| | | | | | | | | | | 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.
* Fix `belongs_to_counter_cache_after_update` to respect polymorphic type changeRyuta Kamizono2018-05-271-1/+12
|
* Fix `belongs_to_counter_cache_after_update` to respect custom primary key ↵Ryuta Kamizono2018-05-261-1/+7
| | | | | | | | | | 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.
* Fix `different_target?` to respect custom primary key counterRyuta Kamizono2018-05-261-0/+7
|
* Eager loading won't mutate owner recordRyuta Kamizono2018-05-251-0/+8
| | | | | | | | | | | | | | | 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.
* Fix `CustomCops/AssertNot` to allow it to have failure messageRyuta Kamizono2018-05-133-6/+6
| | | | Follow up of #32605.
* Allow a belonging to object to be created from a new recordJolyon Pawlyn2018-05-011-0/+9
| | | | 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.
* Merge pull request #32727 from utilum/assert_dont_expectsRafael França2018-04-271-9/+13
|\ | | | | Use MethodCallAssertions instead of mocha expects
| * assert_calledutilum2018-04-261-3/+4
| |
| * assert_not_calledutilum2018-04-261-6/+9
| |
* | Ensure that `ids_reader` respects dirty target whether target is loaded or notRyuta Kamizono2018-04-271-2/+2
| | | | | | | | | | | | | | 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.
* | Merge pull request #32617 from tgturner/size-should-use-available-associationRyuta Kamizono2018-04-271-0/+74
|\ \ | | | | | | Loaded associations should not run a new query when size is called
| * | Loaded associations should not run a new query when size is calledGraham Turner2018-04-261-0/+74
| |/ | | | | | | | | | | | | 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
* / Add test case that assigning belongs_to on destroyed object raises frozen errorRyuta Kamizono2018-04-271-0/+7
|/ | | | | This is to ensure that the behavior has not changed before and after #31575.
* Using existing models for building multiple has_one through testsRyuta Kamizono2018-04-221-16/+12
| | | | Follow up of #32514.
* Merge pull request #32514 from ↵Ryuta Kamizono2018-04-221-0/+22
|\ | | | | | | | | samdec/multiple-has-one-through-associations-build-bug Fix .new with multiple through associations
| * Fix .new with multiple through associationsSam DeCesare2018-04-091-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Add test case for `collection.size` with dirty targetRyuta Kamizono2018-04-211-0/+10
| |
* | Can preload associations through polymorphic associationsDana Sherson2018-04-201-0/+29
| |
* | Replace `assert !` with `assert_not`Daniel Colson2018-04-195-6/+6
|/ | | | | This autocorrects the violations after adding a custom cop in 3305c78dcd.
* Autocorrect `refute` RuboCop violationsDaniel Colson2018-04-032-2/+2
| | | | | | 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!
* Fix intermittent CI failure due to setting explicit `person.id = 10`Ryuta Kamizono2018-03-301-4/+0
| | | | https://travis-ci.org/rails/rails/jobs/360109429
* Don't unset foreign key when preloading missing recordEugene Kenny2018-03-241-0/+2
| | | | | | | | | 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.
* Fix dependence on has_one/belongs_to relationshipsFernando Gorodscy2018-03-062-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Eager loading with polymorphic associations should behave consistentlyRyuta Kamizono2018-03-041-2/+4
| | | | | | | | | | 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.
* Extract all `base_class.name` as `polymorphic_name`Ryuta Kamizono2018-03-041-9/+23
| | | | | | | 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.
* Fix "NameError: uninitialized constant Categorization::Category"yuuji.yaginuma2018-02-261-0/+1
| | | | | | | | 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
* Merge pull request #31895 from ↵Ryuta Kamizono2018-02-261-0/+10
|\ | | | | | | | | kamipo/do_not_attempt_to_find_inverse_of_polymorphic Make `reflection.klass` raise if `polymorphic?` not to be misused
| * Make `reflection.klass` raise if `polymorphic?` not to be misusedRyuta Kamizono2018-02-191-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Association creation and finding should work consistently (#32048)Ryuta Kamizono2018-02-261-5/+35
|/ | | | | | | | | | | 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.
* Association scope's own order should be prioritized over through scope's orderRyuta Kamizono2018-02-181-0/+7
| | | | | | | | | | 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.
* Deprecate update_attributes and update_attributes!Eddie Lebow2018-02-172-7/+7
| | | | Closes #31998
* Merge pull request #31934 from fatkodima/fix-has_many_through-dumpingRyuta Kamizono2018-02-091-0/+5
|\ | | | | | | Fix marshaling of models with `has_many :through` associations
| * Fix marshaling of models with `has_many :through` associationsfatkodima2018-02-081-0/+6
|/
* Remove extra whitespaceDaniel Colson2018-01-254-25/+25
|
* Use assert_empty and assert_not_emptyDaniel Colson2018-01-259-68/+68
|
* Use assert_predicate and assert_not_predicateDaniel Colson2018-01-2513-242/+242
|
* Use respond_to test helpersDaniel Colson2018-01-251-1/+1
|
* Fix building has_one through recordRyuta Kamizono2018-01-231-0/+12
| | | | Fixes #31762.
* Don't update counter cache when through record was not destroyedEugene Kenny2018-01-141-0/+10
| | | | | | 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.
* Merge pull request #23146 from piotrj/issue_18424Ryuta Kamizono2018-01-111-0/+19
|\ | | | | | | When deleting through records, take into account association conditions
| * When deleting through records, take into account association conditionsPiotr Jakubowski2016-05-041-0/+16
| | | | | | | | | | | | | | | | 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.
* | Fix `stale_state` for nested `has_many :through` associationsRyuta Kamizono2018-01-101-12/+28
| | | | | | | | Need reloading when through record has replaced.
* | Merge pull request #16314 from ↵Ryuta Kamizono2018-01-101-0/+29
|\ \ | | | | | | | | | | | | | | | zoltankiss/allow-nested-has-many-associations-on-unpersisted-parent-instances fix nested `has many :through` associations on unpersisted parent instances
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-18 01:26:40 +0000