I was working on another branch and as part of my commit, Rubocop
removed a validation (but not the spec that asserted the validation).
Below is the "non-updating" rubocop offense on the other branch.
```shell
❯ rubocop ./app/models/notification_subscription.rb
Inspecting 1 file
C
Offenses:
app/models/notification_subscription.rb:13:29: C: [Correctable]
Rails/RedundantPresenceValidationOnBelongsTo: Remove explicit presence
validation for notifiable_id.
validates :notifiable_id, presence: true
^^^^^^^^^^^^^^
1 file inspected, 1 offense detected, 1 offense auto-correctable
```
To remediate, I ran:
```shell
> rubocop --only "Rails/RedundantPresenceValidationOnBelongsTo" \
--auto-correct
```
This resolved the `app/models`. Then did some regex magic and removed
the assertions from `spec/models`.
For Forem folks, I wrote a [forem.team post][1] discuss if this is how
we want to proceed.
[1]:https://forem.team/jeremy/rubocop-auto-updating-mayhem-33a6
* Favoring dependent: :delete_all over :destroy
The `dependent: :destroy` callback is slower than `dependent: :delete`
and `dependent: :delete_all`. We need only favor the `dependent:
:destroy` when there's callbacks that happen.
In the case of :destroy, ActiveRecord instantiates each object and then
runs destroy. Whereas in the case of :delete, ActiveRecord issues a SQL
command to delete the related files.
It is often "safer" to use :destroy, as it guarantees that you'll
instantiate the record and run it's callbacks. But sometimes you have
to go with the speed of SQL.
This relates to #14140. Note there is still more to consider, but given
that we're looking at moving from :destroy on all of an article's page
views to :delete, we might buy enough time in the callback.
* Removing redundancy of article destroy
Prior to this commit, `before_destroy_actions` called the `bust_cache`
method which in turn called `touch_actor_latest_article_updated_at` but
`bust_cache` did not pass the destroying parameter. Then
`before_destroy_actions` immediately called
`touch_actor_latest_article_updated_at` with `destroying: true`.
With this change, we remove one of those duplicate calls.
* Fixing specs regarding relationships
* Fixing specs regarding relationships
* Favoring delete_all on user relationships
Prior to this commit, several of the user's "has_many" were marked as
`depenedent: :destroy`.
In the case of :destroy, ActiveRecord instantiates each object and then
runs destroy. Whereas in the case of :delete, ActiveRecord issues a SQL
command to delete the related files.
It is often "safer" to use :destroy, as it guarantees that you'll
instantiate the record and run it's callbacks. But sometimes you have
to go with the speed of SQL.
And while not directly related to #15424 it is representative of our
callback ecosystem creating some unexpected computational loads.
Related to #15442 and #15424
* Noting models that user no longer cascade destroys
* Add MVP of notification subscriptions
* Add rate limiting for notification subscriptions
* Show modal for logged out users on subscribe click
* Add enter key functionality for checkbox
* Add relationships for notification subscriptions
* Add model test for notification subscription
* Deprecated article mutes in favor of notification subscriptions
* Deprecated comment mutes in favor of notification subscriptions
* Move comment muting tests and logic over
* Merge comment and article muting into subscriptions
* Remove redundant check
* Use database to check for rate limit instead of cache
* Test for subscriptions handling notifications properly
* Fix notification model spec for subscriptions
* Fix tests for subscriptions
* Remove rate limiting
* Properly handle logged out users getting subscription status
* Fix test for new pattern
* Update reserved words
* Add config column to notification subscriptions
* Add logic for top level config and move tests
* Test for top level subscribers getting notified
* Fix logic mistake oops
* Add index and refactor comment_user_ids
