| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
Fix habtm reflection
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/counter_cache.rb
activerecord/lib/active_record/reflection.rb
activerecord/test/cases/reflection_test.rb
|
|
|
|
| |
this change was unneccsary as nothing was gained from it
|
|
|
|
|
|
|
| |
Rename delete_all_records because this name better describes
what the method is doing. We can then remove :all from the
hm:t version and pull out the unoptimized call to load_target
in delete_records and pass it directly.
|
|
|
|
|
|
| |
Refactor delete_count method to only handle delete_all or nullify/nil cases
and not destroy and switch to if/else rather than case statement. This
refactoring allows removal of :all symbol usage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor by creating two methods delete_all_records and delete_records
to be called by delete_all and delete (or destroy) respectively.
This reduces the number of conditionals required to handle _how_
records get deleted.
The new delete_count method handles how scope is applied to which
delete action.
A delete_all_records method also has to be called in has_many_through
association because of how the methods are chained. This will be
refactored later on.
|
| |
|
|
|
|
|
|
| |
Apparently we've been using a buggy feature for the past 6 years:
https://bugs.ruby-lang.org/issues/9593
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
| |
|
|
|
|
|
| |
This reverts commit 9dc8aef084fc5ae7e3a396dd098d89da93d06fda, reversing
changes made to 02e8dae6279ea25312293a3eca777faf35139c4c.
|
|
|
|
| |
restrict_dependent_destroy errors
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When removing records from a `has_many` association it used
the `primary_key` defined on the association.
Our test suite didn't fail because on all occurences of `:primary_key`,
the specified column was available in both tables. This prevented the
code from raising an exception but it still behaved badly.
I added a test-case to prevent regressions that failed with:
```
1) Error:
HasManyAssociationsTest#test_has_many_assignment_with_custom_primary_key:
ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: essays.first_name: UPDATE "essays" SET "writer_id" = NULL WHERE "essays"."writer_id" = ? AND "essays"."first_name" IS NULL
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit https://github.com/rails/rails/pull/9668 shows warning
when `delete_all` is invoked with `:dependent` option
`:destroy`.
Unfortunately invoking `Post.destroy_all` invokes
`post.comments.delete_all` as part of `has_many` callbacks.
This commit ensures that instead `post.comments.destroy_all` is
invoked and in the process no warning is generated.
See issue #9567 for details .
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This reverts commit 3803fcce26b837c0117f7d278b83c366dc4ed370.
Conflicts:
activerecord/CHANGELOG.md
It will be deprecated only in 4.0, and removed properly in 4.1.
|
| |
|
| |
|
|
|
|
| |
Bug #6289
|
| |
|
|
|
|
| |
present but the record is unsaved
|
|
|
|
|
|
|
| |
If we're deleting all records in an association, don't add a IN(..)
clause to the query.
Fixes #3672.
|
|
|
|
| |
Fixes #1360.
|
| |
|
|
|
|
| |
AssociationScope class which is capable of building a scope for any association.
|
|
|
|
| |
callbacks etc) rather than calling a whole bunch of methods with rather long names.
|
|
|
|
| |
'reflection.options' with 'options'. Also add through_options and source_options methods for through associations.
|
|
|
|
| |
accessing the instance variables
|
|
|
|
| |
manages the association, and a CollectionProxy class which is *only* a proxy. Singular associations no longer have a proxy. See CHANGELOG for more.
|
| |
|
|
|
|
| |
be more consistent with each other, and to stop passing blocks around, thus making the execution easier to follow.
|
|
|
|
| |
state:resolved]. Also fixed a bunch of other counter cache bugs in the process, as once I fixed this one others started appearing like nobody's business.
|
|
|
|
| |
records in the join table. This is to make the destroy method more consistent across the different types of associations. For more details see the CHANGELOG entry.
|
| |
|
| |
|
|
|
|
| |
rather than a hash which is passed to apply_finder_options. This allows more flexibility in how the scope is created, for example because scope.where(a, b) and scope.where(a).where(b) mean different things.
|
| |
|
| |
|
|
|
|
| |
removing test_polymorphic_has_many_going_through_join_model_with_disabled_include, since this specifies different behaviour for an association than for a regular scope. It seems reasonable to expect scopes and association proxies to behave in roughly the same way rather than having subtle differences.
|
|
|
|
| |
options key which it relates to is :foreign_key
|
| |
|