3.17.0版本包含计算列、审计列、模式匹配、反应式事务和Kotlin Coroutine支持
这个版本延续了前几个版本的工作,围绕更复杂的SQL转换功能,包括:
- 用于读和写操作的客户端计算列
- 审计列
- 模式匹配的SQL转换
- 更多的隐式 JOIN 功能
客户端计算列
在所有商业发行版中,一个突破性的新核心功能是,新的客户端计算列功能,建立在jOOQ 3.16的 商业支持的只读列和服务器端计算列之上。
并非所有的RDBMS都支持计算列(例如使用标准的SQL语法 GENERATED ALWAYS AS
),如果它们支持,它们可能不支持STORED
(写时计算)和VIRTUAL
(读时计算)这两种变体。jOOQ现在可以在客户端模拟这两种功能,通过转换你的SQL查询:
STORED
影响 , , , 和INSERT
UPDATE
DELETE
MERGE
VIRTUAL
影响 和DML语句的 子句。要利用这些功能,请将它们与新的合成列生成功能相结合。SELECT
RETURNING
与服务器端的对应功能不同,这些客户端的功能可以产生任意的表达式,包括:
- 隐式连接
- 标量子查询
MULTISET
子查询- 更多
可以把它看作是用jOOQ编写的 "视图",以每一列为基础。一个特别有用的功能组合是将这些计算列与新的可见性修改器结合起来,允许保持计算列(或基础列)的私有性,从而使用户代码看不见。
审计列
STORED
客户端计算列的一个特殊情况是审计列,其最基本的实现形式是:
CREATED_AT
CREATED_BY
MODIFIED_AT
MODIFIED_BY
存在其他的审计方法,包括软删除,额外的元数据,(双)时间版本,但这些列是最流行的方法之一,使这个商业上唯一的便利功能对很多客户非常有用。
jOOQ开源版的Java 17基线
Java 17已经是最新的LTS,它包括很多非常酷的功能,包括:
- 密封类型(对模式匹配至关重要)
- 记录
- instanceof模式匹配
- 文本块
- 开关表达式
jOOQ 3.16的实验性新查询对象模型(QOM)API对密封类型进行了实验,一旦QOM API最终确定,它将被更广泛地采用。
为了获得更广泛的用户对这些改进的反馈,以及接受Java新的LTS更新节奏,我们决定将Java 17作为jOOQ 3.17开源版的基线,继续在商业jOOQ发行版中支持Java 8和11。
以下旧的jOOQ版本将继续接受升级:
- jOOQ 3.14:最后一个在jOOQ开源版 中支持Java 8的版本,在jOOQ企业版中支持Java 6。
- jOOQ 3.15和3.16:jOOQ开源 版支持Java 11的最后一个版本。
支持PostgreSQL的数据类型
jooq-postgres-extensions模块,包含了对HSTORE
类型的支持,现在对PostgreSQL特定的数据类型有了更多的支持,包括每个的数组类型:
CIDR
CITEXT
LTREE
HSTORE
INET
RANGE
(包括对 , , 等的所有特殊化)INT4
INT8
为了从这些数据类型中获利,只需在你的代码生成和运行时依赖中添加org.jooq:jooq-postgres-extensions
模块,这些类型就会自动生成。
隐式JOIN的改进
在这个版本中,我们试验了一些新的隐式JOIN功能,包括对DML语句中隐式JOIN的支持。目前的实现产生了相关的子查询,在DML语句中不支持JOIN。
我们还试验了为其他常用的相关子查询创建一个 "方便的语法",例如EXISTS(...)
子查询或MULTISET(...)
子查询。这个实验非常有趣。但是,原型却被拒绝了,请看这里的讨论:
未来的jOOQ版本将以更多的隐式JOIN功能的形式实现所需的便利性,同时提供隐式to-many JOIN的功能。
原型的一个遗留问题是,你现在可以更容易地在你的SELECT
子句中投射除经典Field<T>
以外的表达式即:
Table<R>
now extendsSelectField<R>
Condition
现在扩展Field<Boolean>
这意味着你可以写一个这样的查询:
Result<Record3<CustomerRecord, AddressRecord, Boolean>> result =
ctx.select(
// Project a CustomerRecord directly
CUSTOMER,
// Project an AddressRecord from an implicit JOIN
CUSTOMER.address(),
// Project a boolean expression, instead of wrapping it with field()
exists(
selectOne()
.from(PAYMENT)
.where(PAYMENT.CUSTOMER_ID.eq(CUSTOMER.CUSTOMER_ID))
)
.from(CUSTOMER)
.fetch();
模式匹配的SQL转换
SQL转换是最近的jOOQ版本的一个战略性功能集,为商业客户提供了SQL方言之间的额外兼容性,例如:
- 将Oracle的
ROWNUM
转化为等价的窗口函数或LIMIT
条款。 - 将包括Oracle的
(+)
操作符的表列表转为ANSI JOIN语法。
这个版本有一个新的商业功能,在渲染前直接转换新的查询对象模型(QOM)的表达式树。它是通过对表达式树应用模式匹配来实现的。一些各种各样的例子包括:
LTRIM(RTRIM(x))
成TRIM(x)
x != a AND x != b
变成x NOT IN (a, b)
x IN (a, b, c) AND x IN (b, c, d)
进入x IN (b, c)
NOT (NOT (x = 1))
进入x = 1
NOT (x = 1)
进入x != 1
还有更多,这个功能的主要使用情况是:
- SQL检查,例如,作为一个
ExecuteListener
- SQL自动清理,包括在
ParsingConnection
- 方言迁移,当升级数据库版本,或在方言之间移动时
- 对特定的SQL功能进行修补
反应式和kotlin coroutine支持
很多小的改进已经实现。几个比较重要的,包括:
- 现在支持R2DBC 0.9.1.RELEASE。
- 增加了一个新的反应式事务API,它提供了与现有的阻塞式事务API相同的嵌套 事务语义,另见: blog.jooq.org/nested-tran…
- 通过
Publisher
SPI的jOOQ的反应式流绑定现在 ,在新的org.jooq:jooq-kotlin-coroutines
模块中使用通常的utilitesorg.jetbrains.kotlinx:kotlinx-coroutines-core
和 自动桥接到kotlin coroutines。org.jetbrains.kotlinx:kotlinx-coroutines-reactor
org.jooq:jooq-kotlin
扩展模块现在有额外的 扩展函数,以获得更多的MULTISET
和其他嵌套相关的 便利。- 整个阻塞执行API现在被注释为
org.jetbrains.annotations.Blocking
,以帮助反应式jOOQ用户 ,避免在使用IntelliJ时意外地阻塞查询。此外,我们 ,现在用同一软件包中的ApiStatus
注解来注释实验性和内部API。
转载自:https://juejin.cn/post/7126030955013210148