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

2022-03-30 本文已影响0人码哥说

前言

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

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

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

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

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

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

能省不少事.

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

直到某天生产爆雷

大佬找到我

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

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

于是, 问题就出现了, 本以为更新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

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

订阅号.png