破圈的一些复杂的逻辑处理

黄鹏宇 97 2023-11-21

一、 自动已读

【√】1. 当审批申请后 /apply/{apply_id}/approval

对该消息自动已读,对应的消息为:

type = "apply"
resource_id = #postID
user_id = #user_id

【√】2. 查看自己在某个帖子下的审批详情后 /apply/{apply_id}/invite

自动已读,对应的消息为:

type = "pass"
resource_id = #apply_id
user_id = #user_id

二、 删除资源

1. 删除帖子

对帖子、申请、创建者消息、申请者消息做处理

【√】a. 帖子

帖子删除,缓存清除

【√】b. 申请

所有的apply,标记为related_post_deleted

【√】c. 创建者消息

帖子拥有者的消息做处理,标记【对应资源已被删除】

user_id
type= "apply"
resource_id = #postID
【√】d. 申请者消息

申请过该帖子的人,他们的pass消息做处理,标记【对应资源已被删除】:

感觉不如在数据库中,再存个post_id,apply_id ? 但以后太多关联类型了怎么办?
以后可能要有一个msg_related_rel => 消息关联的多个实体,都放在里面做映射 ?

拿出applyList,这里只能遍历,因为msg里存的是apply_id…

type= "pass"
resource_id = #apply_id
【√】 e. 缓存
  1. 未读消息缓存
    帖子拥有者和[ 创建申请的人 ] 的未读消息都设为
    change_flag = true
  2. 删除帖子的缓存

2. 删除申请

对申请、创建者消息、申请者消息做处理

【√】a. 申请

标记为已删除 delete = 0

【√】b. 创建者消息

如果这条申请是pending状态,则需要标记为【对应资源已被删除】

type= "apply"
resource_id = #post_id
sender_user = #删除者ID
【√】c. 申请者消息

如果这条申请是accept状态,则需要标记【对应资源已被删除】

type= "pass"
resource_id = #apply_id
【√】d. 删除帖子缓存

三、由于增加了related_resource_deleted,引入的新问题

1. 未读消息

deleted = 0
is_read = 0
related_resource_deleted = 0

2. 获取自己在某个帖子下的apply?

没这种场景,因为帖子都已经被删除了