我想使用Quarkus中的JOOQ DSL来构建我的SQL（希望执行它们）。
因此，我添加了以下 quarkus jooq伸展。
由于我想使用反应性 pg sql client 我在我的项目中，我在问我自己，如果 fetch（） JOOQ的方法会阻止线程吗？它是与引擎盖下的反应性VERTX客户端兼容还是使用阻止？看起来后一个，因为它不会返回未来或类似的东西。
在这种情况下，我可能只应该使用JOOQ来创建SQL字符串。
I want to use the JOOQ DSL in Quarkus to build my SQL (and hopefully execute them).
Therefore I added the following Quarkus JOOQ extension.
Since I want to use the reactive PG SQL Client in my project, I'm asking myself if e.g. the fetch() method of JOOQ will block the thread ? Is it compatible with the reactive vertx client under the hood or does it use a blocking one ? Looks like the latter one since it doesn't return a future or anything like that.
In that case I propably should only use JOOQ for creating the SQL string.
发布评论
评论（2）
JOOQ API的哪些部分可以反应地使用
JOOQ的
resultsquery＆lt; rt;扩展Publisher＆lt＆gt;，因此您只能将JOOQ查询放置在任何反应流中的实现中。 JOOQ中有3个主publisher子类型：resultquery＆lt; r＆gt;扩展publisher＆lt; r＆gt;Publisher code>从jooq 3.17开始，还将有一种方法来创建
考虑到这一点，在反应世界中，您无需调用任何传统的JOOQ阻止执行方法。您总是会通过一些反应流集成隐式执行JOOQ查询。
避免呼叫阻止API
从JOOQ 3.17开始，所有阻止API（例如
resultquery.fetch（））将被注释为org.jetbrains.annotations.blocking.blocking，因此您获得IDE支持以警告您即将在非障碍环境中做可能没有意义的事情。为任何此操作的支持实现
，您需要为JOOQ提供 r2dbc 连接。 R2DBC是一种SPI，可以在诸如JOOQ和R2DBC驱动程序之类的客户端库之间进行互操作性，例如 Flow api集成在JDK 9中。
将来可能会有一些工作来支持替代性非阻滞驱动程序，但是在添加反应性支持时R2DBC似乎是最可互操作的选择，我确实希望Vert.x和R2DBC团队能找到方法来找到方法将来更加紧密地合作。例如，Vert.x SQL客户端并未直接实现反应流SPI，Red Hat似乎并不太感兴趣（目前）在此处继续此处： https://github.com/eclipse-vertx/vertx-sql-client/issues/249
所以，现在，就目前，现在，这意味着您必须要做：
sultiSet依赖于jooq执行查询的副标 。
当然，要考虑您是否真的需要进行反应，这总是很重要 根据我的个人经验，这主要是针对编程样式的问题，而不是实际的性能和/或负载要求。坚持阻止范式和JDBC将大大简化您的每日工作，我怀疑您会发现生产的差异。
Which parts of the jOOQ API can be used reactively
jOOQ's
ResultQuery<R>extendsPublisher<R>, so you can just place a jOOQ query in any reactive stream implementation. There are 3 mainPublishersubtypes in jOOQ:ResultQuery<R>extendsPublisher<R>RowCountQueryextendsPublisher<Integer>BatchextendsPublisher<Integer>And starting with jOOQ 3.17, there will also be a way to create transactional
Publishertypes.With this in mind, in the reactive world, you will never need to call any of the traditional jOOQ blocking execution methods. You'll always implicitly execute jOOQ queries via some reactive streams integration.
Avoiding calls to blocking API
Starting with jOOQ 3.17, all the blocking API (e.g.
ResultQuery.fetch()) will be annotated asorg.jetbrains.annotations.Blocking, so you get IDE support to warn you that you're about to do something that might not make sense in your non-blocking context.Backing implementation
For any of this to work, you need to provide jOOQ with an R2DBC connection. R2DBC is an SPI that enables interoperability between client libraries like jOOQ and R2DBC drivers, like r2dbc-postgres. Just like JDBC, it works as an SPI, not strictly an API. Besides, it integrates also directly with the reactive streams SPI, which has been integrated in the JDK 9 via the
FlowAPI.There might be future work to support alternative non-blocking drivers in the future, however R2DBC seemed to be the most interoperable choice at the time the reactive support was added, and I do hope that the Vert.x and R2DBC teams will find ways to cooperate more tightly in the future. The Vert.x SQL client, for example, does not implement the reactive streams SPI directly, Red Hat does not seem too interested (yet) in moving forward with this issue here: https://github.com/eclipse-vertx/vertx-sql-client/issues/249
So, for now, this means that you have to either:
MULTISET, which relies on jOOQ executing your query)A side note on reactive execution
Of course, it's always important to think about whether you really need to go reactive. In my personal experience, this is mostly a matter of programming style, not actual performance and/or load requirements. Sticking with the blocking paradigm and JDBC will greatly simplify your every day work, and I doubt you'll notice a measurable difference in production.
我正在寻找一种解决方案来做同样的事情，我还没有测试过它，但是我遇到了此仓库：
https://github.com/jklingsporn/vertx-jooq
使用quarkus中的vert.x完全重新进行。
I'm looking for a solution to do the same thing, I haven't tested it yet but I came across this repo:
https://github.com/jklingsporn/vertx-jooq
https://github.com/jklingsporn/quarkus-jooq-reactive-example
It may help to be fully reative using vert.x in quarkus.