・
Reviews 13
・
Average rating 4.8
If you have some knowledge, it's comfortable to listen to. However, there are many codes(?) that reflect personal styles, such as visually checking by printing logs in the unit test code, or calling repo.save in the modify method, so it seems difficult for beginners to properly integrate it to their own style. If you have enough knowledge to filter out and absorb things like "There are people who write this way, Oh, that looks good," it's a pretty good lecture for review.
If it is a normal creation situation, there is no need to save( ) when modifying (dirty checking) For dirty checking, the entity object must be guaranteed to be persistent. However, sometimes when working with other developers, I see code like the following. @Transactional // User entity unrelated to the persistence context connected to the transaction boundary public void saveRefreshToken(User user, String newRefreshToken) { ... user.setRefreshToken(newRefreshToken); ... } In this case, the User object is not subject to dirty checking. I thought that using save( ) to prepare for these situations is not an anti-pattern. -------------------------- ChatGPT Spring Data JPA provides two main approaches to changing the state of an entity: change detection (dirty checking) and using the save() method. Each method can be used appropriately depending on the specific situation. Below, I will explain the pros and cons of each method and their use cases. --------------------. Conclusion Which method to use depends on the situation. Change detection is suitable for simple and small transactions, and explicit save method (save()) is suitable for large transactions with clear and complex business logic. In practice, the two methods are usually used interchangeably. Change detection is used for simple CRUD operations, and when complex business logic is required, the save() method is used to explicitly manage it.
Oh, there are situations like that too. I'm learning again. Thank you.