前言
用过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
网友评论