实际例子使用Hibernate FlushMode.ALWAYS
您能给我一些在 Hibernate 会话中使用 FlushMode.ALWAYS 的实际示例吗?
谢谢,
Could you give me some practical examples that use FlushMode.ALWAYS in Hibernate session?
Thanks,
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
这几乎总是不必要的。如果在会话中进行的修改在刷新到数据库时导致一些修改,并且 Hibernate 无法检测到这些修改,那么它可能会很有用。例如,如果对表 A 的某些插入导致触发器执行,如果该触发器向表 B 插入行,并且如果您对表 B 执行查询。在这种情况下,Hibernate 无法检测到之前需要刷新会话执行HQL查询。
It's almost always unnecessary. It could be useful if the modifications made in the session cause some modifications when flushed in database, and these modifications can't be detected by Hibernate. For example, if some insert to table A causes a trigger to execute, if this trigger inserts rows to table B, and if you execute a query on table B. In this case, Hibernate can't detect that flushing the session is needed before the HQL query is executed.
我遇到过需要这样做的情况。下面是一个案例:
表 A 对 B 列有唯一约束。您希望在单个事务中删除 r1 并插入 r2,其中 r1.B == r2.B。单个事务中的 Hibernate 重新排序导致了 UniqueConstraintViolation。 FlushMode.ALWAYS 在这里有帮助,或者您可以执行显式 session.flush()。
I have encountered cases where it was required. One case is below:
Table A has a unique constraint on column B. You want to delete r1 and insert r2 in a single transaction, where r1.B == r2.B. Hibernate reordering within the single transaction caused a UniqueConstraintViolation. FlushMode.ALWAYS helps out here or you could do an explicit session.flush().
测试
对于
@Transactional
,测试的默认/隐含行为是@Rollback(true)
...对于< hibernate这意味着底层数据库根本不参与。无论您在表上定义了什么约束,它们也不会被评估。如果您的测试违反了其中一些约束,您将不会知道,测试将顺利通过。直到您将@Rollback
覆盖为false
,或通过flush()
或FlushMode.ALWAYS
强制刷新。Tests
With
@Transactional
the default/implied behaviour for tests is@Rollback(true)
... With Hibernate this means that the underlying database does not get involved at all. And whatever constraints you have defined on your tables they will not be evaluated either. Should your tests violate some of those constraints you will not know about it, the tests will be passing happily. Until you override@Rollback
tofalse
, or enforce the flush viaflush()
orFlushMode.ALWAYS
.