2019-05-03 06:17:27 +08:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2013-03-01 20:07:44 +08:00
|
|
|
class Notification < ActiveRecord::Base
|
2024-08-27 10:56:00 +08:00
|
|
|
self.ignored_columns = [
|
|
|
|
:old_id, # TODO: Remove when column is dropped. At this point, the migration to drop the column has not been writted.
|
|
|
|
]
|
|
|
|
|
2023-12-08 01:30:44 +08:00
|
|
|
attr_accessor :acting_user
|
|
|
|
attr_accessor :acting_username
|
|
|
|
|
2013-02-06 03:16:51 +08:00
|
|
|
belongs_to :user
|
|
|
|
belongs_to :topic
|
|
|
|
|
2021-01-28 00:29:24 +08:00
|
|
|
has_one :shelved_notification
|
|
|
|
|
2019-11-28 06:32:35 +08:00
|
|
|
MEMBERSHIP_REQUEST_CONSOLIDATION_WINDOW_HOURS = 24
|
|
|
|
|
2013-02-06 03:16:51 +08:00
|
|
|
validates_presence_of :data
|
|
|
|
validates_presence_of :notification_type
|
|
|
|
|
2013-03-01 02:54:12 +08:00
|
|
|
scope :unread, lambda { where(read: false) }
|
2015-06-22 20:32:45 +08:00
|
|
|
scope :recent,
|
|
|
|
lambda { |n = nil|
|
|
|
|
n ||= 10
|
|
|
|
order("notifications.created_at desc").limit(n)
|
|
|
|
}
|
2015-06-23 04:14:22 +08:00
|
|
|
scope :visible,
|
|
|
|
lambda {
|
|
|
|
joins("LEFT JOIN topics ON notifications.topic_id = topics.id").where(
|
|
|
|
"topics.id IS NULL OR topics.deleted_at IS NULL",
|
|
|
|
)
|
|
|
|
}
|
2022-09-30 13:44:04 +08:00
|
|
|
scope :unread_type, ->(user, type, limit = 30) { unread_types(user, [type], limit) }
|
|
|
|
scope :unread_types,
|
2023-11-29 13:38:07 +08:00
|
|
|
->(user, types, limit = 30) do
|
2022-09-30 13:44:04 +08:00
|
|
|
where(user_id: user.id, read: false, notification_type: types)
|
|
|
|
.visible
|
|
|
|
.includes(:topic)
|
|
|
|
.limit(limit)
|
2023-11-29 13:38:07 +08:00
|
|
|
end
|
2022-11-16 10:32:05 +08:00
|
|
|
scope :prioritized,
|
2023-11-29 13:38:07 +08:00
|
|
|
->(deprioritized_types = []) do
|
2022-11-16 10:32:05 +08:00
|
|
|
scope = order("notifications.high_priority AND NOT notifications.read DESC")
|
PERF: Add indexes to speed up notifications queries by user menu (#26048)
Why this change?
There are two problematic queries in question here when loading
notifications in various tabs in the user menu:
```
SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL)
ORDER BY notifications.high_priority AND NOT notifications.read DESC,
NOT notifications.read AND notifications.notification_type NOT IN (5,19,25) DESC,
notifications.created_at DESC
LIMIT 30;
```
and
```
EXPLAIN ANALYZE SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338
AND (topics.id IS NULL OR topics.deleted_at IS NULL)
AND "notifications"."notification_type" IN (5, 19, 25)
ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read DESC, notifications.created_at DESC LIMIT 30;
```
For a particular user, the queries takes about 40ms and 26ms
respectively on one of our production instance where the user has 10K notifications while the site has 600K notifications in total.
What does this change do?
1. Adds the `index_notifications_user_menu_ordering` index to the `notifications` table which is
indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read)
DESC, created_at DESC)`.
1. Adds a second index `index_notifications_user_menu_ordering_deprioritized_likes` to the `notifications`
table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read AND notification_type NOT IN (5,19,25)) DESC, created_at DESC)`. Note that we have to hardcode the like typed notifications type here as it is being used in an ordering clause.
With the two indexes above, both queries complete in roughly 0.2ms. While I acknowledge that there will be some overhead in insert,update or delete operations. I believe this trade-off is worth it since viewing notifications in the user menu is something that is at the core of using a Discourse forum so we should optimise this experience as much as possible.
2024-03-06 16:52:19 +08:00
|
|
|
|
2022-11-16 10:32:05 +08:00
|
|
|
if deprioritized_types.present?
|
|
|
|
scope =
|
|
|
|
scope.order(
|
|
|
|
DB.sql_fragment(
|
|
|
|
"NOT notifications.read AND notifications.notification_type NOT IN (?) DESC",
|
|
|
|
deprioritized_types,
|
2023-01-09 20:20:10 +08:00
|
|
|
),
|
2022-11-16 10:32:05 +08:00
|
|
|
)
|
|
|
|
else
|
|
|
|
scope = scope.order("NOT notifications.read DESC")
|
|
|
|
end
|
PERF: Add indexes to speed up notifications queries by user menu (#26048)
Why this change?
There are two problematic queries in question here when loading
notifications in various tabs in the user menu:
```
SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL)
ORDER BY notifications.high_priority AND NOT notifications.read DESC,
NOT notifications.read AND notifications.notification_type NOT IN (5,19,25) DESC,
notifications.created_at DESC
LIMIT 30;
```
and
```
EXPLAIN ANALYZE SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338
AND (topics.id IS NULL OR topics.deleted_at IS NULL)
AND "notifications"."notification_type" IN (5, 19, 25)
ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read DESC, notifications.created_at DESC LIMIT 30;
```
For a particular user, the queries takes about 40ms and 26ms
respectively on one of our production instance where the user has 10K notifications while the site has 600K notifications in total.
What does this change do?
1. Adds the `index_notifications_user_menu_ordering` index to the `notifications` table which is
indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read)
DESC, created_at DESC)`.
1. Adds a second index `index_notifications_user_menu_ordering_deprioritized_likes` to the `notifications`
table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read AND notification_type NOT IN (5,19,25)) DESC, created_at DESC)`. Note that we have to hardcode the like typed notifications type here as it is being used in an ordering clause.
With the two indexes above, both queries complete in roughly 0.2ms. While I acknowledge that there will be some overhead in insert,update or delete operations. I believe this trade-off is worth it since viewing notifications in the user menu is something that is at the core of using a Discourse forum so we should optimise this experience as much as possible.
2024-03-06 16:52:19 +08:00
|
|
|
|
2022-11-16 10:32:05 +08:00
|
|
|
scope.order("notifications.created_at DESC")
|
2023-11-29 13:38:07 +08:00
|
|
|
end
|
PERF: Add indexes to speed up notifications queries by user menu (#26048)
Why this change?
There are two problematic queries in question here when loading
notifications in various tabs in the user menu:
```
SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL)
ORDER BY notifications.high_priority AND NOT notifications.read DESC,
NOT notifications.read AND notifications.notification_type NOT IN (5,19,25) DESC,
notifications.created_at DESC
LIMIT 30;
```
and
```
EXPLAIN ANALYZE SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338
AND (topics.id IS NULL OR topics.deleted_at IS NULL)
AND "notifications"."notification_type" IN (5, 19, 25)
ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read DESC, notifications.created_at DESC LIMIT 30;
```
For a particular user, the queries takes about 40ms and 26ms
respectively on one of our production instance where the user has 10K notifications while the site has 600K notifications in total.
What does this change do?
1. Adds the `index_notifications_user_menu_ordering` index to the `notifications` table which is
indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read)
DESC, created_at DESC)`.
1. Adds a second index `index_notifications_user_menu_ordering_deprioritized_likes` to the `notifications`
table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read AND notification_type NOT IN (5,19,25)) DESC, created_at DESC)`. Note that we have to hardcode the like typed notifications type here as it is being used in an ordering clause.
With the two indexes above, both queries complete in roughly 0.2ms. While I acknowledge that there will be some overhead in insert,update or delete operations. I believe this trade-off is worth it since viewing notifications in the user menu is something that is at the core of using a Discourse forum so we should optimise this experience as much as possible.
2024-03-06 16:52:19 +08:00
|
|
|
|
2022-09-30 13:44:04 +08:00
|
|
|
scope :for_user_menu,
|
2023-11-29 13:38:07 +08:00
|
|
|
->(user_id, limit: 30) do
|
2022-09-30 13:44:04 +08:00
|
|
|
where(user_id: user_id).visible.prioritized.includes(:topic).limit(limit)
|
2023-11-29 13:38:07 +08:00
|
|
|
end
|
2013-03-01 02:54:12 +08:00
|
|
|
|
2017-06-12 15:41:39 +08:00
|
|
|
attr_accessor :skip_send_email
|
|
|
|
|
2017-08-31 12:06:56 +08:00
|
|
|
after_commit :refresh_notification_count, on: %i[create update destroy]
|
REFACTOR: Improve support for consolidating notifications. (#14904)
* REFACTOR: Improve support for consolidating notifications.
Before this commit, we didn't have a single way of consolidating notifications. For notifications like group summaries, we manually removed old ones before creating a new one. On the other hand, we used an after_create callback for likes and group membership requests, which caused unnecessary work, as we need to delete the record we created to replace it with a consolidated one.
We now have all the consolidation rules centralized in a single place: the consolidation planner class. Other parts of the app looking to create a consolidable notification can do so by calling Notification#consolidate_or_save!, instead of the default Notification#create! method.
Finally, we added two more rules: one for re-using existing group summaries and another for deleting duplicated dashboard problems PMs notifications when the user is tracking the moderator's inbox. Setting the threshold to one forces the planner to apply this rule every time.
I plan to add plugin support for adding custom rules in another PR to keep this one relatively small.
* DEV: Introduces a plugin API for consolidating notifications.
This commit removes the `Notification#filter_by_consolidation_data` scope since plugins could have to define their criteria. The Plan class now receives two blocks, one to query for an already consolidated notification, which we'll try to update, and another to query for existing ones to consolidate.
It also receives a consolidation window, which accepts an ActiveSupport::Duration object, and filter notifications created since that value.
2021-12-01 00:36:14 +08:00
|
|
|
after_commit :send_email, on: :create
|
2016-12-22 12:29:34 +08:00
|
|
|
|
2019-11-28 07:01:55 +08:00
|
|
|
after_commit(on: :create) { DiscourseEvent.trigger(:notification_created, self) }
|
2019-08-16 02:45:30 +08:00
|
|
|
|
2020-04-01 07:09:20 +08:00
|
|
|
before_create do
|
2020-05-07 12:35:32 +08:00
|
|
|
# if we have manually set the notification to high_priority on create then
|
|
|
|
# make sure that is respected
|
|
|
|
self.high_priority =
|
|
|
|
self.high_priority || Notification.high_priority_types.include?(self.notification_type)
|
2020-04-01 07:09:20 +08:00
|
|
|
end
|
|
|
|
|
REFACTOR: Improve support for consolidating notifications. (#14904)
* REFACTOR: Improve support for consolidating notifications.
Before this commit, we didn't have a single way of consolidating notifications. For notifications like group summaries, we manually removed old ones before creating a new one. On the other hand, we used an after_create callback for likes and group membership requests, which caused unnecessary work, as we need to delete the record we created to replace it with a consolidated one.
We now have all the consolidation rules centralized in a single place: the consolidation planner class. Other parts of the app looking to create a consolidable notification can do so by calling Notification#consolidate_or_save!, instead of the default Notification#create! method.
Finally, we added two more rules: one for re-using existing group summaries and another for deleting duplicated dashboard problems PMs notifications when the user is tracking the moderator's inbox. Setting the threshold to one forces the planner to apply this rule every time.
I plan to add plugin support for adding custom rules in another PR to keep this one relatively small.
* DEV: Introduces a plugin API for consolidating notifications.
This commit removes the `Notification#filter_by_consolidation_data` scope since plugins could have to define their criteria. The Plan class now receives two blocks, one to query for an already consolidated notification, which we'll try to update, and another to query for existing ones to consolidate.
It also receives a consolidation window, which accepts an ActiveSupport::Duration object, and filter notifications created since that value.
2021-12-01 00:36:14 +08:00
|
|
|
def self.consolidate_or_create!(notification_params)
|
|
|
|
notification = new(notification_params)
|
|
|
|
consolidation_planner = Notifications::ConsolidationPlanner.new
|
|
|
|
|
|
|
|
consolidated_notification = consolidation_planner.consolidate_or_save!(notification)
|
|
|
|
|
|
|
|
consolidated_notification == :no_plan ? notification.tap(&:save!) : consolidated_notification
|
|
|
|
end
|
|
|
|
|
2020-02-24 08:42:50 +08:00
|
|
|
def self.purge_old!
|
|
|
|
return if SiteSetting.max_notifications_per_user == 0
|
|
|
|
|
|
|
|
DB.exec(<<~SQL, SiteSetting.max_notifications_per_user)
|
|
|
|
DELETE FROM notifications n1
|
|
|
|
USING (
|
|
|
|
SELECT * FROM (
|
|
|
|
SELECT
|
|
|
|
user_id,
|
|
|
|
id,
|
|
|
|
rank() OVER (PARTITION BY user_id ORDER BY id DESC)
|
|
|
|
FROM notifications
|
|
|
|
) AS X
|
|
|
|
WHERE rank = ?
|
|
|
|
) n2
|
|
|
|
WHERE n1.user_id = n2.user_id AND n1.id < n2.id
|
|
|
|
SQL
|
|
|
|
end
|
|
|
|
|
2013-05-16 15:50:14 +08:00
|
|
|
def self.ensure_consistency!
|
2020-04-01 07:09:20 +08:00
|
|
|
DB.exec(<<~SQL)
|
2017-04-25 04:51:09 +08:00
|
|
|
DELETE
|
|
|
|
FROM notifications n
|
2021-09-14 22:57:38 +08:00
|
|
|
WHERE high_priority
|
2022-03-30 22:56:35 +08:00
|
|
|
AND n.topic_id IS NOT NULL
|
2017-04-25 04:51:09 +08:00
|
|
|
AND NOT EXISTS (
|
|
|
|
SELECT 1
|
|
|
|
FROM posts p
|
|
|
|
JOIN topics t ON t.id = p.topic_id
|
|
|
|
WHERE p.deleted_at IS NULL
|
|
|
|
AND t.deleted_at IS NULL
|
|
|
|
AND p.post_number = n.post_number
|
|
|
|
AND t.id = n.topic_id
|
|
|
|
)
|
|
|
|
SQL
|
2013-05-16 15:50:14 +08:00
|
|
|
end
|
|
|
|
|
2013-03-01 20:07:44 +08:00
|
|
|
def self.types
|
2016-01-08 18:53:52 +08:00
|
|
|
@types ||=
|
|
|
|
Enum.new(
|
|
|
|
mentioned: 1,
|
|
|
|
replied: 2,
|
|
|
|
quoted: 3,
|
|
|
|
edited: 4,
|
|
|
|
liked: 5,
|
|
|
|
private_message: 6,
|
|
|
|
invited_to_private_message: 7,
|
|
|
|
invitee_accepted: 8,
|
|
|
|
posted: 9,
|
|
|
|
moved_post: 10,
|
|
|
|
linked: 11,
|
|
|
|
granted_badge: 12,
|
|
|
|
invited_to_topic: 13,
|
|
|
|
custom: 14,
|
2016-01-27 18:38:14 +08:00
|
|
|
group_mentioned: 15,
|
2016-07-07 03:56:40 +08:00
|
|
|
group_message_summary: 16,
|
2017-05-17 02:49:42 +08:00
|
|
|
watching_first_post: 17,
|
2019-01-16 10:40:16 +08:00
|
|
|
topic_reminder: 18,
|
|
|
|
liked_consolidated: 19,
|
2019-06-11 09:17:23 +08:00
|
|
|
post_approved: 20,
|
2019-08-06 18:29:46 +08:00
|
|
|
code_review_commit_approved: 21,
|
2019-11-28 06:32:35 +08:00
|
|
|
membership_request_accepted: 22,
|
2020-03-12 08:16:00 +08:00
|
|
|
membership_request_consolidated: 23,
|
2020-07-27 09:39:50 +08:00
|
|
|
bookmark_reminder: 24,
|
|
|
|
reaction: 25,
|
2020-08-07 07:51:16 +08:00
|
|
|
votes_released: 26,
|
2020-08-19 18:07:51 +08:00
|
|
|
event_reminder: 27,
|
2021-07-20 03:52:12 +08:00
|
|
|
event_invitation: 28,
|
2021-09-14 22:57:38 +08:00
|
|
|
chat_mention: 29,
|
|
|
|
chat_message: 30,
|
2022-01-18 22:26:27 +08:00
|
|
|
chat_invitation: 31,
|
2022-03-16 21:55:21 +08:00
|
|
|
chat_group_mention: 32, # March 2022 - This is obsolete, as all chat_mentions use `chat_mention` type
|
2022-03-17 04:08:10 +08:00
|
|
|
chat_quoted: 33,
|
2022-03-28 16:03:19 +08:00
|
|
|
assigned: 34,
|
|
|
|
question_answer_user_commented: 35, # Used by https://github.com/discourse/discourse-question-answer
|
2022-12-14 07:22:26 +08:00
|
|
|
watching_category_or_tag: 36,
|
2022-12-16 01:12:53 +08:00
|
|
|
new_features: 37,
|
2023-05-04 00:35:22 +08:00
|
|
|
admin_problems: 38,
|
2024-04-10 01:53:37 +08:00
|
|
|
linked_consolidated: 39,
|
2024-09-02 20:45:55 +08:00
|
|
|
chat_watched_thread: 40,
|
2022-12-19 12:57:35 +08:00
|
|
|
following: 800, # Used by https://github.com/discourse/discourse-follow
|
|
|
|
following_created_topic: 801, # Used by https://github.com/discourse/discourse-follow
|
|
|
|
following_replied: 802, # Used by https://github.com/discourse/discourse-follow
|
2023-01-13 01:07:42 +08:00
|
|
|
circles_activity: 900, # Used by https://github.com/discourse/discourse-circles
|
2016-01-27 18:38:14 +08:00
|
|
|
)
|
2013-02-06 03:16:51 +08:00
|
|
|
end
|
|
|
|
|
2020-04-01 07:09:20 +08:00
|
|
|
def self.high_priority_types
|
|
|
|
@high_priority_types ||= [types[:private_message], types[:bookmark_reminder]]
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.normal_priority_types
|
|
|
|
@normal_priority_types ||= types.reject { |_k, v| high_priority_types.include?(v) }.values
|
|
|
|
end
|
|
|
|
|
2013-02-25 15:42:42 +08:00
|
|
|
def self.mark_posts_read(user, topic_id, post_numbers)
|
2018-05-26 09:11:10 +08:00
|
|
|
Notification.where(
|
2018-05-28 16:41:38 +08:00
|
|
|
user_id: user.id,
|
|
|
|
topic_id: topic_id,
|
|
|
|
post_number: post_numbers,
|
|
|
|
read: false,
|
2018-05-26 08:09:48 +08:00
|
|
|
).update_all(read: true)
|
2013-02-06 03:16:51 +08:00
|
|
|
end
|
|
|
|
|
2016-09-16 14:14:00 +08:00
|
|
|
def self.read(user, notification_ids)
|
2017-04-25 04:51:09 +08:00
|
|
|
Notification.where(id: notification_ids, user_id: user.id, read: false).update_all(read: true)
|
2022-08-03 20:32:35 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
def self.read_types(user, types = nil)
|
|
|
|
query = Notification.where(user_id: user.id, read: false)
|
|
|
|
query = query.where(notification_type: types) if types
|
|
|
|
query.update_all(read: true)
|
2016-09-16 14:14:00 +08:00
|
|
|
end
|
|
|
|
|
2013-02-06 03:16:51 +08:00
|
|
|
def self.interesting_after(min_date)
|
|
|
|
result =
|
|
|
|
where("created_at > ?", min_date)
|
|
|
|
.includes(:topic)
|
2015-02-19 09:40:00 +08:00
|
|
|
.visible
|
2013-02-06 03:16:51 +08:00
|
|
|
.unread
|
|
|
|
.limit(20)
|
2013-03-01 20:07:44 +08:00
|
|
|
.order(
|
|
|
|
"CASE WHEN notification_type = #{Notification.types[:replied]} THEN 1
|
|
|
|
WHEN notification_type = #{Notification.types[:mentioned]} THEN 2
|
2013-02-06 03:16:51 +08:00
|
|
|
ELSE 3
|
|
|
|
END, created_at DESC",
|
2023-01-09 20:20:10 +08:00
|
|
|
)
|
2013-02-06 03:16:51 +08:00
|
|
|
.to_a
|
|
|
|
|
|
|
|
# Remove any duplicates by type and topic
|
|
|
|
if result.present?
|
2013-02-07 23:45:24 +08:00
|
|
|
seen = {}
|
2013-02-06 03:16:51 +08:00
|
|
|
to_remove = Set.new
|
|
|
|
|
|
|
|
result.each do |r|
|
|
|
|
seen[r.notification_type] ||= Set.new
|
|
|
|
if seen[r.notification_type].include?(r.topic_id)
|
2013-02-07 23:45:24 +08:00
|
|
|
to_remove << r.id
|
2013-02-06 03:16:51 +08:00
|
|
|
else
|
|
|
|
seen[r.notification_type] << r.topic_id
|
|
|
|
end
|
|
|
|
end
|
2013-02-07 23:45:24 +08:00
|
|
|
result.reject! { |r| to_remove.include?(r.id) }
|
2013-02-06 03:16:51 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
result
|
|
|
|
end
|
|
|
|
|
2014-05-27 01:26:28 +08:00
|
|
|
# Clean up any notifications the user can no longer see. For example, if a topic was previously
|
|
|
|
# public then turns private.
|
|
|
|
def self.remove_for(user_id, topic_id)
|
|
|
|
Notification.where(user_id: user_id, topic_id: topic_id).delete_all
|
|
|
|
end
|
|
|
|
|
2023-10-13 09:41:10 +08:00
|
|
|
def self.filter_inaccessible_topic_notifications(guardian, notifications)
|
|
|
|
topic_ids = notifications.map { |n| n.topic_id }.compact.uniq
|
|
|
|
accessible_topic_ids = guardian.can_see_topic_ids(topic_ids: topic_ids)
|
|
|
|
notifications.select { |n| n.topic_id.blank? || accessible_topic_ids.include?(n.topic_id) }
|
|
|
|
end
|
|
|
|
|
2013-02-06 03:16:51 +08:00
|
|
|
# Be wary of calling this frequently. O(n) JSON parsing can suck.
|
|
|
|
def data_hash
|
2019-12-05 23:05:39 +08:00
|
|
|
@data_hash ||=
|
|
|
|
begin
|
|
|
|
return {} if data.blank?
|
2016-02-23 08:34:16 +08:00
|
|
|
|
2019-12-05 23:05:39 +08:00
|
|
|
parsed = JSON.parse(data)
|
|
|
|
return {} if parsed.blank?
|
2015-09-04 11:34:21 +08:00
|
|
|
|
2019-12-05 23:05:39 +08:00
|
|
|
parsed.with_indifferent_access
|
|
|
|
end
|
2013-02-06 03:16:51 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
def url
|
2016-02-02 02:12:10 +08:00
|
|
|
topic.relative_url(post_number) if topic.present?
|
2013-02-06 03:16:51 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
def post
|
2013-03-01 02:54:12 +08:00
|
|
|
return if topic_id.blank? || post_number.blank?
|
2014-05-06 21:41:59 +08:00
|
|
|
Post.find_by(topic_id: topic_id, post_number: post_number)
|
2013-02-06 03:16:51 +08:00
|
|
|
end
|
2013-05-16 13:03:03 +08:00
|
|
|
|
PERF: Add indexes to speed up notifications queries by user menu (#26048)
Why this change?
There are two problematic queries in question here when loading
notifications in various tabs in the user menu:
```
SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL)
ORDER BY notifications.high_priority AND NOT notifications.read DESC,
NOT notifications.read AND notifications.notification_type NOT IN (5,19,25) DESC,
notifications.created_at DESC
LIMIT 30;
```
and
```
EXPLAIN ANALYZE SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338
AND (topics.id IS NULL OR topics.deleted_at IS NULL)
AND "notifications"."notification_type" IN (5, 19, 25)
ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read DESC, notifications.created_at DESC LIMIT 30;
```
For a particular user, the queries takes about 40ms and 26ms
respectively on one of our production instance where the user has 10K notifications while the site has 600K notifications in total.
What does this change do?
1. Adds the `index_notifications_user_menu_ordering` index to the `notifications` table which is
indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read)
DESC, created_at DESC)`.
1. Adds a second index `index_notifications_user_menu_ordering_deprioritized_likes` to the `notifications`
table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read AND notification_type NOT IN (5,19,25)) DESC, created_at DESC)`. Note that we have to hardcode the like typed notifications type here as it is being used in an ordering clause.
With the two indexes above, both queries complete in roughly 0.2ms. While I acknowledge that there will be some overhead in insert,update or delete operations. I believe this trade-off is worth it since viewing notifications in the user menu is something that is at the core of using a Discourse forum so we should optimise this experience as much as possible.
2024-03-06 16:52:19 +08:00
|
|
|
# Update `index_notifications_user_menu_ordering_deprioritized_likes` index when updating this as this is used by
|
|
|
|
# `Notification.prioritized_list` to deprioritize like typed notifications. Also See
|
|
|
|
# `db/migrate/20240306063428_add_indexes_to_notifications.rb`.
|
2022-11-16 10:32:05 +08:00
|
|
|
def self.like_types
|
|
|
|
[
|
|
|
|
Notification.types[:liked],
|
2022-11-16 12:37:51 +08:00
|
|
|
Notification.types[:liked_consolidated],
|
|
|
|
Notification.types[:reaction],
|
2022-11-16 10:32:05 +08:00
|
|
|
]
|
|
|
|
end
|
|
|
|
|
2022-09-13 02:19:25 +08:00
|
|
|
def self.prioritized_list(user, count: 30, types: [])
|
|
|
|
return [] if !user&.user_option
|
|
|
|
|
|
|
|
notifications =
|
|
|
|
user
|
|
|
|
.notifications
|
|
|
|
.includes(:topic)
|
|
|
|
.visible
|
2022-11-16 10:32:05 +08:00
|
|
|
.prioritized(types.present? ? [] : like_types)
|
2022-09-30 13:44:04 +08:00
|
|
|
.limit(count)
|
2022-09-13 02:19:25 +08:00
|
|
|
|
|
|
|
if types.present?
|
|
|
|
notifications = notifications.where(notification_type: types)
|
|
|
|
elsif user.user_option.like_notification_frequency ==
|
|
|
|
UserOption.like_notification_frequency_type[:never]
|
2022-11-16 10:32:05 +08:00
|
|
|
like_types.each do |notification_type|
|
2022-09-13 02:19:25 +08:00
|
|
|
notifications = notifications.where("notification_type <> ?", notification_type)
|
|
|
|
end
|
|
|
|
end
|
|
|
|
notifications.to_a
|
|
|
|
end
|
|
|
|
|
2022-07-25 20:19:53 +08:00
|
|
|
def self.recent_report(user, count = nil, types = [])
|
2016-03-06 06:21:38 +08:00
|
|
|
return unless user && user.user_option
|
|
|
|
|
2014-02-14 04:20:56 +08:00
|
|
|
count ||= 10
|
2015-02-19 09:40:00 +08:00
|
|
|
notifications = user.notifications.visible.recent(count).includes(:topic)
|
2016-03-06 06:21:38 +08:00
|
|
|
|
2022-07-25 20:19:53 +08:00
|
|
|
notifications = notifications.where(notification_type: types) if types.present?
|
2016-03-06 06:21:38 +08:00
|
|
|
if user.user_option.like_notification_frequency ==
|
|
|
|
UserOption.like_notification_frequency_type[:never]
|
2019-01-16 17:08:59 +08:00
|
|
|
[
|
|
|
|
Notification.types[:liked],
|
|
|
|
Notification.types[:liked_consolidated],
|
|
|
|
].each do |notification_type|
|
|
|
|
notifications = notifications.where("notification_type <> ?", notification_type)
|
|
|
|
end
|
2016-03-06 06:21:38 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
notifications = notifications.to_a
|
2014-02-13 14:12:17 +08:00
|
|
|
|
|
|
|
if notifications.present?
|
2022-07-25 20:19:53 +08:00
|
|
|
builder = DB.build(<<~SQL)
|
2016-02-15 16:29:35 +08:00
|
|
|
SELECT n.id FROM notifications n
|
2022-07-25 20:19:53 +08:00
|
|
|
/*where*/
|
2016-02-15 16:29:35 +08:00
|
|
|
ORDER BY n.id ASC
|
2022-07-25 20:19:53 +08:00
|
|
|
/*limit*/
|
|
|
|
SQL
|
|
|
|
|
|
|
|
builder.where(<<~SQL, user_id: user.id)
|
|
|
|
n.high_priority = TRUE AND
|
|
|
|
n.user_id = :user_id AND
|
|
|
|
NOT read
|
2018-06-19 14:13:14 +08:00
|
|
|
SQL
|
2022-07-25 20:19:53 +08:00
|
|
|
builder.where("notification_type IN (:types)", types: types) if types.present?
|
|
|
|
builder.limit(count.to_i)
|
|
|
|
|
|
|
|
ids = builder.query_single
|
2016-02-15 16:29:35 +08:00
|
|
|
|
|
|
|
if ids.length > 0
|
|
|
|
notifications +=
|
|
|
|
user
|
|
|
|
.notifications
|
|
|
|
.order("notifications.created_at DESC")
|
|
|
|
.where(id: ids)
|
|
|
|
.joins(:topic)
|
|
|
|
.limit(count)
|
|
|
|
end
|
|
|
|
|
|
|
|
notifications
|
|
|
|
.uniq(&:id)
|
|
|
|
.sort do |x, y|
|
2020-04-01 07:09:20 +08:00
|
|
|
if x.unread_high_priority? && !y.unread_high_priority?
|
2014-02-13 14:27:35 +08:00
|
|
|
-1
|
2020-04-01 07:09:20 +08:00
|
|
|
elsif y.unread_high_priority? && !x.unread_high_priority?
|
2014-02-13 14:27:35 +08:00
|
|
|
1
|
|
|
|
else
|
|
|
|
y.created_at <=> x.created_at
|
2023-01-09 20:20:10 +08:00
|
|
|
end
|
2014-02-13 14:27:35 +08:00
|
|
|
end
|
|
|
|
.take(count)
|
|
|
|
else
|
|
|
|
[]
|
|
|
|
end
|
2014-02-13 14:12:17 +08:00
|
|
|
end
|
|
|
|
|
2023-12-08 01:30:44 +08:00
|
|
|
def self.populate_acting_user(notifications)
|
|
|
|
usernames =
|
|
|
|
notifications.map do |notification|
|
|
|
|
notification.acting_username =
|
|
|
|
(
|
|
|
|
notification.data_hash[:username] || notification.data_hash[:display_username] ||
|
|
|
|
notification.data_hash[:mentioned_by_username] ||
|
|
|
|
notification.data_hash[:invited_by_username]
|
|
|
|
)&.downcase
|
|
|
|
end
|
|
|
|
|
|
|
|
users = User.where(username_lower: usernames.uniq).index_by(&:username_lower)
|
|
|
|
notifications.each do |notification|
|
|
|
|
notification.acting_user = users[notification.acting_username]
|
|
|
|
end
|
|
|
|
|
|
|
|
notifications
|
|
|
|
end
|
|
|
|
|
2020-04-01 07:09:20 +08:00
|
|
|
def unread_high_priority?
|
|
|
|
self.high_priority? && !read
|
2014-02-13 14:12:17 +08:00
|
|
|
end
|
2013-05-16 13:03:03 +08:00
|
|
|
|
2016-01-27 09:19:49 +08:00
|
|
|
def post_id
|
2023-02-13 12:39:45 +08:00
|
|
|
Post.where(topic: topic_id, post_number: post_number).pick(:id)
|
2016-01-27 09:19:49 +08:00
|
|
|
end
|
|
|
|
|
2013-05-16 13:03:03 +08:00
|
|
|
protected
|
|
|
|
|
|
|
|
def refresh_notification_count
|
2019-10-23 13:09:55 +08:00
|
|
|
User.find_by(id: user_id)&.publish_notifications_state if user_id
|
2013-05-16 13:03:03 +08:00
|
|
|
end
|
|
|
|
|
2016-12-22 12:29:34 +08:00
|
|
|
def send_email
|
2021-01-28 00:29:24 +08:00
|
|
|
return if skip_send_email
|
|
|
|
|
|
|
|
if user.do_not_disturb?
|
|
|
|
ShelvedNotification.create(notification_id: self.id)
|
2023-01-09 20:20:10 +08:00
|
|
|
else
|
2021-01-28 00:29:24 +08:00
|
|
|
NotificationEmailer.process_notification(self)
|
2023-01-09 20:20:10 +08:00
|
|
|
end
|
2016-12-22 12:29:34 +08:00
|
|
|
end
|
2013-02-06 03:16:51 +08:00
|
|
|
end
|
|
|
|
|
2013-05-24 10:48:32 +08:00
|
|
|
# == Schema Information
|
|
|
|
#
|
|
|
|
# Table name: notifications
|
|
|
|
#
|
|
|
|
# notification_type :integer not null
|
|
|
|
# user_id :integer not null
|
|
|
|
# data :string(1000) not null
|
|
|
|
# read :boolean default(FALSE), not null
|
2014-08-27 13:19:25 +08:00
|
|
|
# created_at :datetime not null
|
|
|
|
# updated_at :datetime not null
|
2013-05-24 10:48:32 +08:00
|
|
|
# topic_id :integer
|
|
|
|
# post_number :integer
|
|
|
|
# post_action_id :integer
|
2020-04-01 07:09:20 +08:00
|
|
|
# high_priority :boolean default(FALSE), not null
|
2024-08-26 09:35:12 +08:00
|
|
|
# id :bigint not null, primary key
|
2013-05-24 10:48:32 +08:00
|
|
|
#
|
|
|
|
# Indexes
|
|
|
|
#
|
2018-07-16 14:18:07 +08:00
|
|
|
# idx_notifications_speedup_unread_count (user_id,notification_type) WHERE (NOT read)
|
2015-09-18 08:41:10 +08:00
|
|
|
# index_notifications_on_post_action_id (post_action_id)
|
2019-10-30 19:59:59 +08:00
|
|
|
# index_notifications_on_topic_id_and_post_number (topic_id,post_number)
|
2015-09-18 08:41:10 +08:00
|
|
|
# index_notifications_on_user_id_and_created_at (user_id,created_at)
|
|
|
|
# index_notifications_on_user_id_and_topic_id_and_post_number (user_id,topic_id,post_number)
|
2020-04-01 07:09:20 +08:00
|
|
|
# index_notifications_read_or_not_high_priority (user_id,id DESC,read,topic_id) WHERE (read OR (high_priority = false))
|
|
|
|
# index_notifications_unique_unread_high_priority (user_id,id) UNIQUE WHERE ((NOT read) AND (high_priority = true))
|
PERF: Add indexes to speed up notifications queries by user menu (#26048)
Why this change?
There are two problematic queries in question here when loading
notifications in various tabs in the user menu:
```
SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338 AND (topics.id IS NULL OR topics.deleted_at IS NULL)
ORDER BY notifications.high_priority AND NOT notifications.read DESC,
NOT notifications.read AND notifications.notification_type NOT IN (5,19,25) DESC,
notifications.created_at DESC
LIMIT 30;
```
and
```
EXPLAIN ANALYZE SELECT "notifications".*
FROM "notifications"
LEFT JOIN topics ON notifications.topic_id = topics.id
WHERE "notifications"."user_id" = 1338
AND (topics.id IS NULL OR topics.deleted_at IS NULL)
AND "notifications"."notification_type" IN (5, 19, 25)
ORDER BY notifications.high_priority AND NOT notifications.read DESC, NOT notifications.read DESC, notifications.created_at DESC LIMIT 30;
```
For a particular user, the queries takes about 40ms and 26ms
respectively on one of our production instance where the user has 10K notifications while the site has 600K notifications in total.
What does this change do?
1. Adds the `index_notifications_user_menu_ordering` index to the `notifications` table which is
indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read)
DESC, created_at DESC)`.
1. Adds a second index `index_notifications_user_menu_ordering_deprioritized_likes` to the `notifications`
table which is indexed on `(user_id, (high_priority AND NOT read) DESC, (NOT read AND notification_type NOT IN (5,19,25)) DESC, created_at DESC)`. Note that we have to hardcode the like typed notifications type here as it is being used in an ordering clause.
With the two indexes above, both queries complete in roughly 0.2ms. While I acknowledge that there will be some overhead in insert,update or delete operations. I believe this trade-off is worth it since viewing notifications in the user menu is something that is at the core of using a Discourse forum so we should optimise this experience as much as possible.
2024-03-06 16:52:19 +08:00
|
|
|
# index_notifications_user_menu_ordering (user_id, ((high_priority AND (NOT read))) DESC, ((NOT read)) DESC, created_at DESC)
|
|
|
|
# index_notifications_user_menu_ordering_deprioritized_likes (user_id, ((high_priority AND (NOT read))) DESC, (((NOT read) AND (notification_type <> ALL (ARRAY[5, 19, 25])))) DESC, created_at DESC)
|
2013-05-24 10:48:32 +08:00
|
|
|
#
|