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

一、 自动已读

【√】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？

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