java

spring

spring-boot

jpa

spring-data-jpa

SpringBoot JPA need no .save() on @Transactional?

Viewed 510 times

I have short question:

Do I need a repo.save(x) call on @Transactional methods?

I ask cause I see changes on my DB without save, and read no clear docs about it.

So is it working as intended, or just a (welcome) unexpected behavior?

example:

@Autowired
private UserRepo repo;

@Transactional  
@PutMapping
public Long put(@RequestBody User user)
{
  User u = repo.findOne(user.getId());
  u.setName("Paul");
  repo.save(u); // DO I NEED THIS LINE?
}

I'am just unsure about it, so maybe someone can shed some light on the subject?

Answers

If you retrieve an entity, for example using the findOne method call within a transactional method it has become managed from that point by the persistence provider.

Now if you make any changes to that entity (which is actually a proxy object), upon transaction commit, those changes will be persisted to the database, regardless of the fact of invoking the save or update methods.

save or persist has to be used when you are creating a new entity from scratch and persistence provider does not know of its existance yet.

Remember that you can prevent making any changes upon commit, if you use detach or evict methods on that particular entity before those changes occur.

Saturday, September 10, 2022

essjae

The save(…) method of the CrudRepository interface is supposed to abstract simply storing an entity no matter what state it is in. Thus it must not expose the actual store specific implementation, even if (as in the JPA) case the store differentiates between new entities to be stored and existing ones to be updated. That's why the method is actually called save(…) not create(…) or update(…). We return a result from that method to actually allow the store implementation to return a completely different instance as JPA potentially does when merge(…) gets invoked.

Also, persistence implementations actually capable of dealing with immutable objects (i.e. not JPA) might have to return a fresh instance if the actual implementation requires populating an identifier or the like. I.e. it's generally wrong to assume that the implementation would just consume the entity state.

So generally it's more of an API decision to be lenient (permissible, tolerant) regarding the actual implementation and thus implementing the method for JPA as we do. There's no additional proxy massaging done to the entities passed.

Sunday, December 25, 2022

bekce

You are making things overly complex by adding Spring Data JPA just to execute a simple insert statement. You aren't using any of the JPA features. Instead do the following

Replace spring-boot-starter-data-jpa with spring-boot-starter-jdbc
Remove your DnitRepository interface
Inject JdbcTemplate where you where injecting DnitRepository
Replace dnitRepository.insertdata(2, someJsonDataAsString ); with jdbcTemplate.executeUpdate("insert into dnit(id, data) VALUES (?,to_json(?))", id, data);

You were already using plain SQL (in a very convoluted way), if you need plain SQL (and don't have need for JPA) then just use SQL.

Ofcourse instead of directly injecting the JdbcTemplate into your controller you probably want to hide that logic/complexity in a repository or service.

Wednesday, December 21, 2022

kheldar

Follow the below steps:

Add an additional datasource configuration to your application.properties.
Set the SQL Dialect to “default” in your application.properties to let Spring autodetect the different SQL Dialects of each datasource
Create a Java Package for each datasource with two nested Packages
Create a Configuration Class for the First database
Create a Configuration Class for the Second database
Create an Entity for the First database
Create a Repository for the First database
Create an Entity for the Second database
Create a Repository for the Second database

Full code is available here,

https://github.com/jahe/spring-boot-multiple-datasources

Above steps are took from this tutorials

https://medium.com/@joeclever/using-multiple-datasources-with-spring-boot-and-spring-data-6430b00c02e7

Hope this will helps:)

Saturday, October 15, 2022

akamath

All your ManyToOne relationships are either non-optional or not-null.

So Hibernate generates INNER JOINS. You have to make sure that your data is following this rules.

If you define non-optional or not null relationships you should also have a NOT NULL constraint on the foreign key in the database table.

Wednesday, August 10, 2022

roberto_russo

Only authorized users can answer the search term. Please sign in first, or register a free account.

Not the answer you're looking for? Browse other questions tagged :