我们什么时候对 setComplete() 使用 hibernate 的会话刷新

发布于 2024-09-27 11:18:12 字数 191 浏览 8 评论 0原文

我在使用单元测试用例时阅读了有关 Hibernate setComplete() 方法的 spring 文档。我对 setComplete() 与 session 的lush() 方法感到困惑。两者都负责通过从内存加载到实际数据库来使对象的状态在数据库中持久化。如果有人可以帮助我获得与此相关的良好资源/示例,那就太好了。我将非常感激。

谢谢, 毛利克

I've read spring documentation regarding Hibernate's setComplete() method while working with Unit Test Cases. I am confused between setComplete() versus session's flush() method. Both are responsible to make object's state persistent in Database by loading from memory to actual Database. It will be great if somebody can help me to get good resources/examples regarding the same. I will highly appreciate it.

Thanks,
Maulik

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

‖放下 2024-10-04 11:18:12

据我所知, setComplete() 不是 Hibernate API 的一部分(请在引用某些内容时提供链接),它是 AbstractTransactionalSpringContextTests 这是一个基于 JUnit 3.8 的测试的便捷基类,应该在事务中进行,但通常会在每次测试完成时回滚事务setComplete( ) 方法允许更改此默认事务行为。来自其 Javadoc:

导致事务提交此测试方法,即使默认设置为回滚也是如此。

文档的以下部分提供了更具体的用例:

8.3.6.3。事务管理

AbstractTransactionalSpringContextTests
取决于一个
PlatformTransactionManager bean
在应用程序中定义
语境。名字并不重要
按类型使用自动装配。

通常您会延长
子类,
AbstractTransactionalDataSourceSpringContextTests
这个类还需要一个
DataSource bean 定义 - 再次,
以任何名字 - 出现在
应用程序上下文。它创建了一个
JdbcTemplate 实例变量,即
对于方便查询很有用,并且
提供了方便的方法来删除
所选表格的内容(记住
事务将回滚
默认值,因此这是安全的)。

如果您想要提交事务
以编程方式 - 不寻常,但是
当你想要一个特定的测试来填充
数据库
- 您可以调用
setComplete() 方法继承自
AbstractTransactionalSpringContextTests
这将导致交易
提交而不是回滚。作为一个
另一种选择,如果您正在开发
针对 Java 5 或更高版本以及
延伸
AbstractAnnotationAwareTransactionalTests< /代码>
你可以用注释你的测试方法
@Rollback(false) 实现相同的效果
通过配置来实现效果。

还有方便的能力
在测试之前结束事务
案件结束,通过调用
endTransaction() 方法。这将
默认回滚事务
并仅在 setComplete() 时提交
之前已被调用。这
如果您愿意,该功能很有用
测试“断开连接”的行为
数据对象,例如 Hibernate 映射
将在网络或中使用的实体
事务之外的远程处理层。
通常,延迟加载错误是
仅通过 UI 测试发现;如果
你调用endTransaction()你可以
确保UI的正确操作
通过您的 JUnit 测试套件。

Hibernate 的 Session#flush() 非常不同,它只是告诉 Hibernate 将挂起的更改写入数据库,它不与事务交互。

To my knowledge, setComplete() is not part of Hibernate's API (please provide a link when you are referring to something), it is part of the API of AbstractTransactionalSpringContextTests which is a convenient base class for JUnit 3.8 based tests that should occur in a transaction, but normally will roll the transaction back on the completion of each test. The setComplete() method allows to alter this default transactional behavior. From its Javadoc:

Cause the transaction to commit for this test method, even if default is set to rollback.

The following section of the documentation gives more concrete use cases:

8.3.6.3. Transaction management

AbstractTransactionalSpringContextTests
depends on a
PlatformTransactionManager bean
being defined in the application
context. The name doesn't matter due
to the use of autowire by type.

Typically you will extend the
subclass,
AbstractTransactionalDataSourceSpringContextTests.
This class also requires that a
DataSource bean definition - again,
with any name - be present in the
application context. It creates a
JdbcTemplate instance variable, that
is useful for convenient querying, and
provides handy methods to delete the
contents of selected tables (remember
that the transaction will roll back by
default, so this is safe to do).

If you want a transaction to commit
programmatically - unusual, but
occasionally useful when you want a particular test to populate the
database
- you can call the
setComplete() method inherited from
AbstractTransactionalSpringContextTests.
This will cause the transaction to
commit instead of roll back. As an
alternative, if you are developing
against Java 5 or greater and
extending
AbstractAnnotationAwareTransactionalTests,
you may annotate your test method with
@Rollback(false) to achieve the same
effect through configuration.

There is also the convenient ability
to end a transaction before the test
case ends, by calling the
endTransaction() method. This will
roll back the transaction by default
and commit it only if setComplete()
had previously been called. This
functionality is useful if you want to
test the behavior of 'disconnected'
data objects, such as Hibernate-mapped
entities that will be used in a web or
remoting tier outside a transaction.
Often, lazy loading errors are
discovered only through UI testing; if
you call endTransaction() you can
ensure correct operation of the UI
through your JUnit test suite.

Hibernate's Session#flush() is very different, it just tells Hibernate to write pending changes to the database, it doesn't interact with the transaction.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文