共计 1317 个字符,预计需要花费 4 分钟才能阅读完成。
BaseMapper
提供的默认查询方法都是单表的,如果须要多表关联查问,同时还要反对分页,一个计划就是本人写 Sql。
当初本人写 Sql 个别用的应该不是传统 MyBatis 那种写 xml 的老办法,而是通过在 Mapper 类里写注解来实现。
还须要解决的就是如何在自定义 Sql 语句中拼接 MyBatisPlus 的分页参数和查问条件。
示例如下:
public interface GameQueryMapper extends BaseMapper<GameQuery> {
String querySql = "SELECT a.*, b.org_id FROM t_game AS a LEFT JOIN t_game_game_org AS b ON b.game_id = a.id";
String wrapperSql = "SELECT * from (" + querySql + ") AS q ${ew.customSqlSegment}";
/**
* 分页查问
*/
@Select(wrapperSql)
Page<GameQuery> page(Page page, @Param("ew") Wrapper queryWrapper);
/**
* 一般查问
*/
@Select(wrapperSql)
List<GameQuery> list(@Param("ew") Wrapper queryWrapper);
/**
* 独自查问
*/
@Select(wrapperSql)
QyyOrgQuery one(@Param("ew") Wrapper queryWrapper);
}
关键在于 Sql 字符串最初那一句${ew.customSqlSegment}
,是用来拼接 LambdaQueryWrapper 等查问条件包裹器对象最终输入的 Sql 语句的。
后面不能有 WHERE,所以我在最里面又包了一层,将纯正的多表关联查问语句与非凡组装语句辨别开,这样岂但能够在自定义 Sql 外部应用 WHERE 语句,也便于复制和创立新的 Mapper。
但这里还要留神一个关键问题。
在 Mapper 外面自定义 Sql 注解对应的办法,其返回的 Pojo 对象,以及 Mapper 类指定的 Pojo 对象,他们必须完全一致。
即:extends BaseMapper<T>
中的 T 须要与 Page<T>
统一
如果我在 public interface GameMapper extends BaseMapper<Game>
里写了这样一个办法:
Page<GameQuery> page(Page page, @Param("ew") Wrapper queryWrapper);
即便 GameQuery
这个对应多表关联字段的 Pojo 继承自Game
, 也会呈现如下谬误:
evaluating expression 'ew.customSqlSegment'. Cause: org.apache.ibatis.ognl.OgnlException: customSqlSegment [com.baomidou.mybatisplus.core.exceptions.MybatisPlusException: can not find lambda cache for this entity
因而,多表关联分页查问的 Mapper 须要独自新建,与单表实例离开。
正文完