[深圳|结业弟子]JAVA-韦杰|2018年01月14日的日报-技能树.IT修真院

发表于： 2018-01-14 23:20:59

1 640

今天完成的任务

1、首先，我认为，每一次通过编辑后，最终状态为【上架的定时消息】都是为了发送这个定时消息，所以通过编辑上架的定时消息状态只有一个，未完成。另外，在我的设计里，每一条定时消息，最多对应一条timer记录。

注:pushAt为定时消息的推送时间，是时间戳，Long型。pushAt不允许小于当前系统时间。

1）【原-定时消息-上架】-编辑后-【终-定时消息-上架】

原状态未完成-校验pushAt-目标状态未完成

原状态完成-校验pushAt-目标状态未完成

2）【原-定时消息-下架】-编辑后-【终-定时消息-上架】

原状态暂停-校验pushAt-目标状态未完成

原状态未完成-校验pushAt-目标状态未完成

原状态完成-校验pushAt-目标状态未完成

3）【原-即时消息-上架】-编辑后-【终-定时消息-上架】

校验pushAt-创建新的定时消息-目标状态未完成

4）【原-即时消息-下架】-编辑后-【终-定时消息-上架】

校验pushAt-创建新的定时消息-目标状态未完成

所以，如果不管原消息的状态如何，若编辑后保存的状态为【上架的定时消息】，业务逻辑可以统一为：

A、校验pushAt

B、根据要编辑的消息id查timer表得到对应的tid，如果tid=null，则创建一条新的timer记录，该记录的状态设置为未完成

C、如果tid不为null，则修改原纪录的状态，都设置为未完成

2、每次编辑后的最终状态为【下架一个定时消息】，都是为了暂停这个定时消息。

5）【原-定时消息-上架】-编辑后-【终-定时消息-下架】

原状态未完成-目标状态暂停

原状态已完成-目标状态完成

6）【原-定时消息-下架】-编辑后-【终-定时消息-下架】

原状态暂停-目标状态暂停

原状态完成-目标状态完成

7）【原-即时消息-上架】-编辑后-【终-定时消息-下架】

校验pushAt-创建新的定时任务-目标状态暂停

8）【原-即时消息-下架】-编辑后-【终-定时消息-下架】

校验pushAt-创建新的定时任务-目标状态暂停

若编辑后保存的状态为【下架的定时消息】，业务逻辑可以统一为：

1、若原消息为即时消息，转成定时消息时，要先校验pushAt，然后创建新的定时任务，状态为暂停

2、若原消息是定时消息且原状态为完成，则不修改；若原状态为未完成或暂停，则统一修改为暂停

可以看到，通过重新梳理定时消息的编辑规则，把业务逻辑变得没那么复杂。

遇到的问题

收获

明天的计划

1、按照上面的逻辑，重新写“编辑消息”接口

2、后台页面根据时间查询有些问题，前端代码没有把时间传到控制器，需要再修改

进度

返回列表