2022-11-02 21:41:30 +08:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2023-03-17 21:24:38 +08:00
|
|
|
module Chat
|
|
|
|
class Mention < ActiveRecord::Base
|
|
|
|
self.table_name = "chat_mentions"
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
self.ignored_columns = %w[notification_id user_id]
|
2023-03-17 21:24:38 +08:00
|
|
|
|
|
|
|
belongs_to :chat_message, class_name: "Chat::Message"
|
DEV: Allow chat mentions to have several notifications (#24874)
This PR is a reworked version of https://github.com/discourse/discourse/pull/24670.
In chat, we need the ability to have several notifications per `chat_mention`.
Currently, we have one_to_one relationship between `chat_mentions` and `notifications`:
https://github.com/discourse/discourse/blob/d7a09fb08de31dbeed55428b84e0a660dbd5cf7a/plugins/chat/app/models/chat/mention.rb#L9
We want to have one_to_many relationship. This PR implements that by introducing
a join table between `chat_mentions` and `notifications`.
The main motivation for this is that we want to solve some performance problems
with mentions that we're having now. Let's say a user sends a message with @ all
in a channel with 50 members, we do two things in this case at the moment:
- create 50 chat_mentions
- create 50 notifications
We don't want to change how notifications work in core, but we want to be more
efficient in chat, and create only 1 `chat_mention` which would link to 50 notifications.
Also note, that on the side of notifications, having a lot of notifications is not so
big problem, because notifications processing can be queued.
Apart from improving performance, this change will make the code design better.
Note that I've marked the old `chat_mention.notification_id` column as ignored, but
I'm not deleting it in this PR. We'll delete it later in https://github.com/discourse/discourse/pull/24800.
2023-12-19 22:53:00 +08:00
|
|
|
has_many :mention_notifications,
|
|
|
|
class_name: "Chat::MentionNotification",
|
|
|
|
foreign_key: :chat_mention_id
|
|
|
|
has_many :notifications, through: :mention_notifications, dependent: :destroy
|
2023-03-17 21:24:38 +08:00
|
|
|
end
|
2022-11-02 21:41:30 +08:00
|
|
|
end
|
|
|
|
|
|
|
|
# == Schema Information
|
|
|
|
#
|
|
|
|
# Table name: chat_mentions
|
|
|
|
#
|
|
|
|
# id :bigint not null, primary key
|
|
|
|
# chat_message_id :integer not null
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
# target_id :integer
|
|
|
|
# type :integer not null
|
2022-11-02 21:41:30 +08:00
|
|
|
# created_at :datetime not null
|
|
|
|
# updated_at :datetime not null
|
|
|
|
#
|
|
|
|
# Indexes
|
|
|
|
#
|
DEV: Redesign chat mentions (#24752)
At the moment, when someone is mentioning a group, or using here or
all mention, we create a chat_mention record per user. What we want
instead is to have special kinds of mentions, so we can create only one
chat_mention record in such cases. This PR implements that.
Note, that such mentions will still have N related notifications, one
notification per a user. We don't expect we'll have performance
problems on the notifications side, but if at some point we do, we
should be able to solve them on the side of notifications
(notifications are handled in jobs, also some little delays with
the notifications are acceptable, so we can make sure notifications
are properly queued, and that processing of every notification is
fast enough to make delays small enough).
The preparation work for this PR was done in fbd24fa, where we make
it possible for one mention to have several related notifications.
A pretty tricky part of this PR is schema and data migration, I've explained
related details inline on the migration files.
2024-01-17 19:24:01 +08:00
|
|
|
# index_chat_mentions_on_chat_message_id (chat_message_id)
|
|
|
|
# index_chat_mentions_on_target_id (target_id)
|
2022-11-02 21:41:30 +08:00
|
|
|
#
|