闲话少说,进入本期内容的正题。
省流版本:PagerHelper在与PostgreSQL搭配使用时,会有坑!
你如果想知道具体是什么样的一个坑,往下看,我来给大伙儿展开说说。
背景
小黑最近在做一个项目,常规的SpringBoot+Mybatis
架构,数据库使用的是PostgreSQL
,并且有一些场景需要使用到分页查询,很自然的就使用了PageHelper这个分页工具,如果你是初学者或者还没有使用过PageHelper,可以了解一下。PageHelper
到这里一切都很顺利,但是聪明如你一定猜到了,要有什么事情发生。
我需要完成一个数据权限的功能,根据每个用户的数据权限不同,控制每个用户只能查询到自己有权限的用户。
比如用户A只能访问他所在组织的数据,用户B是一个高级用户,能查询到多个组织的数据,用户C是超级管理员,能查询到所有数据等。
实现这个功能我采用的方式是在进行查询时,按照用户的权限不同,增加对应的查询条件。
比如业务方法中SQL是这样的:
select * from t_data where data_id = 1 limit 10 offset 0
复制代码
我需要修改成:
select * from t_data where data_id = 1 and data_part in (1,2,3) limit 10 offset 0
复制代码
这里需要强调一点,就是我不仅要对t_data
这一张表增加条件,还要对其他很多张表加条件,并且可能每张表加的条件还不一样。
我采用了MyBatis的拦截器功能,在拦截器中统一对SQL进行处理,添加数据权限条件。
原以为一切会和我的预期一样,没想到中途踩了一个坑,让我折腾了半晚上。
以上是踩坑的背景,接下来看一下代码。
代码实现
我在拦截器中是这样做的。
MyBatis拦截器实现
/**
* 数据权限拦截器
* 拦截所有MyBatis的查询方法
* @author 小黑说
* @version 1.0
*/
@Intercepts({
@Signature(type = Executor.class, method = "query",args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class}),
@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class, RowBounds.class, ResultHandler.class, CacheKey.class, BoundSql.class})})
public class DataPermissionInterceptor implements Interceptor {
private static final Logger log = LoggerFactory.getLogger(DataPermissionInterceptor.class);
@Override
public Object intercept(Invocation invocation) throws Throwable {
// 这是一个提前处理好的当前用户数据权限的集合,存放在ThreadLocal中。
List<Condition> conditions = DataConditionHelper.getConditions();
// 如果conditions为空代表该用户没有数据权限的限制,可以查询所有数据。
if (CollectionUtils.isEmpty(conditions)) {
return invocation.proceed();
}
Object[] args = invocation.getArgs();
MappedStatement ms = (MappedStatement) args[0];