在 Quarkus 中将 JOOQ 与 Reactive SQL 客户端结合使用

Question

我想使用 Quarkus 中的 JOOQ DSL 来构建我的 SQL（并希望执行它们）。
因此我添加了以下Quarkus JOOQ 扩展。

因为我想在我的项目中使用反应式PG SQL 客户端，所以我问自己fetch()JOOQ 的方法是否会阻塞线程？它与底层的反应式 vertx 客户端兼容还是使用阻塞客户端？看起来像后一种，因为它不会返回未来或类似的东西。

在这种情况下，我可能应该只使用 JOOQ 来创建 SQL 字符串。

Answer 1

jOOQ API 的哪些部分可以反应式使用

jOOQ 的ResultQuery<R>extends Publisher<R>，因此您可以在任何反应式流实现中放置 jOOQ 查询。jOOQ 中有 3 个主要Publisher子类型：

• ResultQuery<R>延伸Publisher<R>
• RowCountQuery延伸Publisher<Integer>
• Batch延伸Publisher<Integer>

并且从 jOOQ 3.17 开始，还将有一种创建事务Publisher类型的方法。

考虑到这一点，在响应式世界中，您将永远不需要调用任何传统的 jOOQ 阻塞执行方法。您将始终通过一些反应式流集成隐式执行 jOOQ 查询。

避免调用阻塞 API

从 jOOQ 3.17 开始，所有阻塞 API（例如ResultQuery.fetch()）都将被注释为org.jetbrains.annotations.Blocking，因此您可以获得 IDE 支持来警告您，您将要做一些在非阻塞上下文中可能没有意义的事情。

支持实施

为了使这些工作正常进行，您需要为 jOOQ 提供R2DBC连接。R2DBC 是一种 SPI，可实现 jOOQ 等客户端库和r2dbc-postgres等 R2DBC 驱动程序之间的互操作性。就像 JDBC 一样，它作为 SPI 工作，而不是严格意义上的 API。此外，它还直接与反应流 SPI 集成，后者已通过FlowAPI 集成到 JDK 9 中。

未来可能会有支持替代非阻塞驱动程序的工作，但是在添加反应式支持时，R2DBC 似乎是最具互操作性的选择，我确实希望 Vert.x 和 R2DBC 团队能够找到方法未来合作更加紧密。例如，Vert.x SQL 客户端并没有直接实现反应式流 SPI，Red Hat 似乎对在此处解决此问题不太感兴趣： https: //github.com/eclipse-vertx/vertx -sql-client/问题/249

因此，目前这意味着您必须：

• 将 jOOQ 与 R2DBC 一起使用，这就是 jOOQ 支持的功能（不确定 Quarkus 是否支持 R2DBC，尽管我没有看到任何不应该支持的理由）
• 仅使用 jOOQ 生成 SQL 并使用 Vert.x 运行 SQL（您将失去很多类型安全性和便利性，以及对高级功能的访问权限MULTISET，例如依赖于 jOOQ 执行查询的功能）

关于反应式执行的旁注

当然，考虑是否真的需要做出反应总是很重要的。根据我个人的经验，这主要是编程风格的问题，而不是实际性能和/或负载要求的问题。坚持使用阻塞范例和 JDBC 将极大地简化您的日常工作，而且我怀疑您是否会注意到生产中的显着差异。