Spring Data JPA - 为什么对返回的实体的更改会自动持久化? [英] Spring Data JPA - Why are changes to a returned Entity automatically persisted?

问题描述

我用一个例子来说明这个问题.

I present the question with an example.

断言我们有一个如下所示的存储库:

Assert that we have a Repository such as the below:

public interface ExampleObjectRepository extends CrudRepository<ExampleObject, Long> {

}

通过扩展JpaRepository接口，ExampleObject存储库继承了如下方法:

By extending the JpaRepository interface, the ExampleObject repository inherits the following method:

T findOne(ID id);

现在，我观察到，如果在调用此方法后收到对 ExampleObject 的引用，我对此方法所做的任何操作都会自动保存到数据库中，例如:

Now, I have observed that, if I receive a reference to an ExampleObject after a call to this method, any manipulations that I make to this method are automatically saved to the database, for example:

ExampleObject pointInCase = exampleObjectRepository.findOne(1L);
pointInCase.setName("Something else");

阅读这个主题，我明白这意味着 ExampleObject 实例是 not detached.

Reading around the subject, I understand this this signfies that ExampleObject instance is not detached.

这与我的预期背道而驰.我原以为我需要使用从 CrudRepository 继承的 save 方法来保存更改:

This goes against my expectations. I would have expected that I would need to use the save method inherited from CrudRepository in order to save the changes:

T save(T entity);

有人愿意确认从 Spring Data JPA Repository 返回的对象仍然作为标准附加，并解释如何使用 API 来标记存储库中的方法，以便它只返回分离的引用吗?

Would anyone be kind enough to confirm that objects returned from a Spring Data JPA Repository remain attached as standard, and explain how to use the API to mark a method in the repository such that it only returns detached references?

我想，当与上述 save(T entity) 方法一起使用时，更改实体的状态也可能会更改其定义，因此我也希望了解如何处理更新的身份.

I imagine that changing the entity's state may also change its definition when it is used with said save(T entity) method, so I would also appreciate an understanding of how identity for updates are handled.

推荐答案

这是 JPA 的基本原则.您使用附加的(托管)实体，并且对这些托管实体所做的每次修改都会自动持久化.

That's a fundamental principle of JPA. You work with attached (managed) entities, and every modification made on these managed entities is automatically made persistent.

如果您不希望更改持久化，则不要进行更改或回滚事务.

If you don't want your changes to be persistent, then don't make changes, or rollback the transaction.

处理分离的实体将是一场噩梦，因为它会阻止延迟加载所有关联.你总是可以在你的实体上调用 EntityManager.detach() ，但我真的不会那样做.试着去理解它是如何工作的并处理它.好处多于坏处.其中之一是，您甚至不必考虑保存复杂业务逻辑可能执行的所有更改，因为这一切都是由 JPA 透明地为您完成的.

Working on detached entities would be a nightmare, because it would prevent lazy-loading all the associations. You can always call EntityManager.detach() on your entities, but I really wouldn't do that. Just try to understand how it works and deal with it. There are much more benefits than disadvantages. One of them being that you don't even have to think about saving all the changes that a complex business logic might do, since it's all done for you by JPA, transparently.

这篇关于Spring Data JPA - 为什么对返回的实体的更改会自动持久化?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！