逻辑删除@TableLogic好是好, 就是要注意细节!

前言

用过MyBatis-Plus的自然知道它的好, 方便省心.

不过在不注意一些特性的情况下, 还是容易踩坑的.

业务系统上针对一些数据的删除, 常常保险的做法就是逻辑删除, 所以开发大佬常常会用个字段来标识一下“删除”状态, 然后不厌其烦的使用“where”来隔离那些删除的数据.

对此, MyBatis-Plus很友善的提供了 @TableLogic 注解来实现逻辑删除功能

@TableLogic(delval = "1", value = "0")
private Integer isDeleted;

只需要对实体类加上注解, 后续但凡你使用MyBatis-Plus自动注入的sql语句, 均会自动补上
"where is_deleted = 0"

能省不少事.

所以, 咸鱼也放心的使用了该注解,

直到某天生产爆雷

大佬找到我

“怎么已删除的数据没法恢复呢?”

问题排查

业务场景大概如下, 系统需要提供MQ监听上游的数据变化, 其中就包含了数据的删除和恢复.

• 删除使用了@TableLogic(delval = "1", value = "0")以及BaseMapper的deleteById()

• 恢复则使用了BaseMapper的updateById()

于是, 问题就出现了, 本以为更新sql是

update is_deleted = 0 where id = xxx

但因为使用了@TableLogic(delval = "1", value = "0"), 和BaseMapper自动注入的方法, 所以最终执行的sql都会拼接上"where is_deleted = 0"

update is_deleted = 0 where id = xxx and is_deleted = 0 

所以最终数据恢复了个寂寞

image.png

参考官网文档说明
https://baomidou.com/pages/6b03c5/#%E4%BD%BF%E7%94%A8%E6%96%B9%E6%B3%95

解决方式

既然用MyBatis-Plus自动注入的sql语句会又问题, 那么只能自己重新完全定义sql来实现数据的逻辑恢复了.

请关注我的订阅号

订阅号.png