每次调用查询中重复的 ORDER BY 数据和条件
Duplicated ORDER BY Data and Conditions In Query Every Time Called
我很久以前就注意到了这一点,并且很久以前就不再让我的 Condition
s 成为私人静态决赛,但我正在为这个问题挠头,因为它有点问题,特别是如果我调试查询。这是示例(我之前在 3.3.x 中看到过这个,尽管我目前使用的是 3.7.3):
final SelectJoinStep<Record13<String, String, String, String, String, BigDecimal, BigDecimal, BigDecimal, String, BigDecimal, String, String, Byte>> query = getSelect()
.from(getFrom(coConditions,
ConditionUtils.buildCondition(cortConditions, removeCortBySpeciality),
ConditionUtils.buildCondition(cosConditions, removeCosBySensitivity), tuConditions,
uaConditions, enableBlackMajik));
final SortField<?>[] orders = new SortField[] {DSL.inline(Integer.valueOf(2)).asc(),
DSL.inline(Integer.valueOf(1)).asc(), DSL.inline(Integer.valueOf(6)).asc()};
if (cosConditions.isPresent()) {
User.logger.error(builder.renderInlined(query.where(cosConditions.get()).orderBy(orders)));
return query.where(cosConditions.get()).orderBy(orders);
}
User.logger.error(builder.renderInlined(query.orderBy(orders)));
return query.orderBy(orders);
这是来自记录器调用的 SQL 片段,仅显示 ORDER BY
:
order by
2 asc,
1 asc,
6 asc
这是发送到 SQL 服务器的 ORDER BY
的 SQL 片段:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
现在,为了进一步展示乐趣,这里是另一个代码片段,只是为了演示这个问题:
User.logger.error(builder.renderInlined(query.orderBy(orders)));
User.logger.error(builder.renderInlined(query.orderBy(orders)));
User.logger.error(builder.renderInlined(query.orderBy(orders)));
return query.orderBy(orders);
第一个记录器调用:
order by
2 asc,
1 asc,
6 asc
第二次记录器调用:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
第三次记录器调用:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
DB 看到的内容:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
现在,我再次注意到我的 Condition
之前的这种行为,每次我调用 Condition
时,它都会被复制到我建立条件和只引用一次(为了一些乐趣而制作的静态引用)。有谁知道我为什么会看到这种行为(并看到类似的行为与条件)?
这是由于 jOOQ 中的一个 API 设计缺陷,jOOQ 已经存在了很长一段时间,将仅在 jOOQ 4.0 中修复 (#2198)。
通常,您不能安全地假设 DSL API 是不可变的(尽管它应该是)。因此,您对 orderBy()
的连续调用实际上每次都会添加 ORDER BY
列集,但您只打印第一个,所以您看不到它。
此处解释了当前行为(滚动到 "mutability"):
http://www.jooq.org/doc/latest/manual/sql-building/sql-statements/dsl-and-non-dsl
我很久以前就注意到了这一点,并且很久以前就不再让我的 Condition
s 成为私人静态决赛,但我正在为这个问题挠头,因为它有点问题,特别是如果我调试查询。这是示例(我之前在 3.3.x 中看到过这个,尽管我目前使用的是 3.7.3):
final SelectJoinStep<Record13<String, String, String, String, String, BigDecimal, BigDecimal, BigDecimal, String, BigDecimal, String, String, Byte>> query = getSelect()
.from(getFrom(coConditions,
ConditionUtils.buildCondition(cortConditions, removeCortBySpeciality),
ConditionUtils.buildCondition(cosConditions, removeCosBySensitivity), tuConditions,
uaConditions, enableBlackMajik));
final SortField<?>[] orders = new SortField[] {DSL.inline(Integer.valueOf(2)).asc(),
DSL.inline(Integer.valueOf(1)).asc(), DSL.inline(Integer.valueOf(6)).asc()};
if (cosConditions.isPresent()) {
User.logger.error(builder.renderInlined(query.where(cosConditions.get()).orderBy(orders)));
return query.where(cosConditions.get()).orderBy(orders);
}
User.logger.error(builder.renderInlined(query.orderBy(orders)));
return query.orderBy(orders);
这是来自记录器调用的 SQL 片段,仅显示 ORDER BY
:
order by
2 asc,
1 asc,
6 asc
这是发送到 SQL 服务器的 ORDER BY
的 SQL 片段:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
现在,为了进一步展示乐趣,这里是另一个代码片段,只是为了演示这个问题:
User.logger.error(builder.renderInlined(query.orderBy(orders)));
User.logger.error(builder.renderInlined(query.orderBy(orders)));
User.logger.error(builder.renderInlined(query.orderBy(orders)));
return query.orderBy(orders);
第一个记录器调用:
order by
2 asc,
1 asc,
6 asc
第二次记录器调用:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
第三次记录器调用:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
DB 看到的内容:
order by
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc,
2 asc,
1 asc,
6 asc
现在,我再次注意到我的 Condition
之前的这种行为,每次我调用 Condition
时,它都会被复制到我建立条件和只引用一次(为了一些乐趣而制作的静态引用)。有谁知道我为什么会看到这种行为(并看到类似的行为与条件)?
这是由于 jOOQ 中的一个 API 设计缺陷,jOOQ 已经存在了很长一段时间,将仅在 jOOQ 4.0 中修复 (#2198)。
通常,您不能安全地假设 DSL API 是不可变的(尽管它应该是)。因此,您对 orderBy()
的连续调用实际上每次都会添加 ORDER BY
列集,但您只打印第一个,所以您看不到它。
此处解释了当前行为(滚动到 "mutability"):
http://www.jooq.org/doc/latest/manual/sql-building/sql-statements/dsl-and-non-dsl