MybatisPlus的逻辑删除与模糊查询的大踩坑

用户管理接口

主要是用户查询和用户删除；

值得注意的是这里的删除并非真正的删除，而是逻辑上的删除，可以查看官方文档的说明：

逻辑删除：

就是将我们设置的isDelete进行值的更新，大抵来说，就是将1变为0；

写完之后，想一下有没有说明问题呢？

注意: 这里一定要进行鉴权，防止接口被恶意调用。

• 因此，现在在数据库当中扩展一个列，是否为管理员。

添加字段

在两段代码中加入判断是否为管理员的逻辑，只有管理员才可以执行这两个操作，现在代码当中已经用了很多的常量了，我们定义一个包，专门写一个接口，定义这些常量，直接引用。

接口中的属性必然是常量，只能读不能改，这样才能为实现接口的对象提供一个统一的属性。

这里由于两段逻辑都用了判断是否为管理员，这里写一个工具类RoleUtils 用于判断是否为管理员，将代码简化。

使用插件mybatisX

• 对于新添加的字段，需要重新generate-mybatisX一下，然后更新UserMapper.xml文件，另外，在配置当中设置一下session的有效时间。
  
  刚才踩到坑了，还以为毁于一旦了呢呜呜，意识到留个“快照”的重要性了，于是火速放到github上面，更新的配置文件还需要改几个参数：
  

模糊查询之大踩坑

于是又踩了一波坑：

• 刚开始，我并没有传入参数，也就是说username是null，然后就进行了模糊查询，打断点调试了一下，发现拿到的数据是空的，但是username是空的时候可以有两个数据啊？然后打断点追踪源码，发现如果传入的是null，最后的模糊查询就会变成%null%
  
  但这在sql当中是不被允许的，于是，必须在controller里面做一次非空判断
  
  紧跟上图，果然是全部数据：
  最后就真相大白辣。

脱敏返回

• 最后优化一下代码，因为返回的user需要脱敏，用户的密码是不能返回出去的，所以写一个工具类调用一下，会比较方便。
  原始的写法：

  return list.stream().map(user->
        {
            user.setUserPassword(null);
            return user;
        }).collect(Collectors.toList());

优化过后的代码：

 List<User> list = userService.list(wrapper);
        List<User> listNew = new ArrayList<>();
       //封装成一个saferty的user 进行返回
        for (User user : list) {
            User safetyUser = SafetyUserUtils.getSafetyUser(user);
            listNew.add(safetyUser);
        }
        return listNew;

好像这样也可以：

List<User> list = userService.list(wrapper);
        return list.stream().map(user->
        SafetyUserUtils.getSafetyUser(user)).collect(Collectors.toList());
       

觉得不错的话，给个小小的爱心哦~