英文:
Batch vs Batched exception handling
问题
I noticed a difference between batch with binder and batched.
In the binder, the spring boot jOOQ exception translator is executed when a DataAccessException occurs. In the batched case, there is no translation, and the exception is directly propagated.
Example:
final BatchBindStep batch = getDslContext().batch(
insertInto( X ).values( (Long) null,);
batch.bind( x ) ) ); --> with loop
batch.execute(); --> exception with translator to spring exception
Example:
getDslContext().batched( configuration ->
// some loop
insertInto( X ).values( "A").execute() --> exception goes not the translator
);
How can I propagate the exception always to the spring jOOQ translator?
Also noticed that I have the same behavior if I throw a jOOQ exception directly.
@Transaction
public foo(){
throw new DataAccessException(""); --> from jOOQ
}
Only the batch.execute() will be translated.
英文:
I noticed a difference between batch with binder and batched.
In the binder the spring boot jooq exception translator is executed when a DataAcessException occurs in the batched case there is no translation and the exception is directly propagated.
Example:
final BatchBindStep batch = getDslContext().batch(
insertInto( X ).values( (Long) null,);
batch.bind( x ) ) ); --> with loop
batch.execute(); --> exception with translator to spring exception
Example:
getDslContext().batched( configuration ->
// some loop
insertInto( X ).values( "A").execute() --> exception goes not the translator
);
How can i propagate the exception always to the spring jOOQ translator?
Also noticed that i have the same behavior if I throw a jOOQ exception directly.
@Transaction
public foo(){
throw new DataAccessException(""); --> from jOOQ
}
Only the batch.execute() will be translated
答案1
得分: 1
这可能是一个 bug，我还不太确定。我已创建了 #14964。
BatchedConnection（例如使用 DSLContext.batched() 提供的）目前不与 ExecuteListener 生命周期集成。这是因为它纯粹在 JDBC 级别实现，并且也可以纯粹在 JDBC 级别使用。
ExecuteListener 生命周期主要与 jOOQ 查询执行相关，而在这种情况下，查询执行被延迟。因此，生命周期在渲染查询和执行它们时通常运行，但像更新计数等内容可能会误导（它们在将查询添加到批处理时是 0，隐式的）。
这意味着目前，来自延迟批处理执行的异常不会路由到任何 ExecuteListener 生命周期，因为它没有可以与之关联的查询上下文。这可能是一个 bug（参见 #14964），但我想知道 Spring 是否仍然能够将生成的 jOOQ DataAccessException 转换为 Spring 的异常。您最后的示例暗示了这可能是值得报告给 Spring Boot 的问题？Spring Boot（据我所知）只有这个 JooqExceptionTranslator 实现，依赖于 ExecuteListener 生命周期。但如果启用了 spring-boot-starter-jooq，它可能能够识别任何类型的 jOOQ DataAccessException。
英文:
This might be a bug, I'm not quite sure yet. I've created #14964.
The BatchedConnection (made available using DSLContext.batched(), for example) currently doesn't integrate with the ExecuteListener lifecycle. This is because it is implemented purely at the JDBC level, and can be used purely at the JDBC level, too.
The ExecuteListener lifecycle is mostly tied to jOOQ query execution, which is delayed in this case. So the lifecycle is run ordinarily when rendering queries and executing them, but things like update counts, etc. may be misleading (they're 0 at the time of adding the query to the batch, implicitly).
This means that currently, an exception originating from the delayed batch execution is not routed to any ExecuteListener lifecycle, because there's no query context that it could be tied to. This is probably a bug (see #14964), but I wonder if Spring shouldn't perhaps still be able to translate the resulting jOOQ DataAccessException to a Spring one. Your last example hints at this being indeed a problem worth reporting to Spring Boot? Spring Boot (to my knowledge) only has this JooqExceptionTranslator implementation, that relies on the ExecuteListener lifecycle. But it could probably recognise any type of jOOQ DataAccessException if the spring-boot-starter-jooq is enabled.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论