You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While evaluating the generator-jhipster-entity-audit Blueprint, we noticed a strange and maybe not desired behaviour of how the generated entityService.update methods do work and what the return value of these are. See also jhipster/generator-jhipster-entity-audit#233
In the generator-jhipster-entity-audit, there are a few Listener generated/filled fields like createdDate/lastModifiedDate. In the "create" case, the default behaviour of Spring Data JPA is to immediately persist it when calling entityRepository.save, therefore making the return value of the entityService.save method be the actual new values (like generated ID).
In the update case, it does not immediately persist/flush by default when calling the entityRepository.save, therefore it returns the old instance value and the actual update/persistence happens, when the @Transactional session is finished (after the entityService.update)... but that means, that also the return value of the entityService.update method is an outdated value, even though, an update happens afterwards in the background. Therefore, the return value is not always reliable.
I just wonder, if it is the responsibility of the generated entityService.update method to return an actually persisted values?
If so, the update method should be changed so that it maybe forces a flush (entityRepository.saveAndFlushinstead of entityRepository.save) or does something different. As otherwise, the return value does not contain the actually persisted value, but possibly something outdated.
Motivation for or Use Case
I'd like to have the correctly persisted values as return value of the service methods.
Overview of the issue
While evaluating the generator-jhipster-entity-audit Blueprint, we noticed a strange and maybe not desired behaviour of how the generated
entityService.update
methods do work and what the return value of these are. See alsojhipster/generator-jhipster-entity-audit#233
In the generator-jhipster-entity-audit, there are a few Listener generated/filled fields like createdDate/lastModifiedDate. In the "create" case, the default behaviour of Spring Data JPA is to immediately persist it when calling
entityRepository.save
, therefore making the return value of theentityService.save
method be the actual new values (like generated ID).In the update case, it does not immediately persist/flush by default when calling the
entityRepository.save
, therefore it returns the old instance value and the actual update/persistence happens, when the@Transactional
session is finished (after theentityService.update
)... but that means, that also the return value of theentityService.update
method is an outdated value, even though, an update happens afterwards in the background. Therefore, the return value is not always reliable.I just wonder, if it is the responsibility of the generated
entityService.update
method to return an actually persisted values?If so, the update method should be changed so that it maybe forces a flush (
entityRepository.saveAndFlush
instead ofentityRepository.save
) or does something different. As otherwise, the return value does not contain the actually persisted value, but possibly something outdated.Motivation for or Use Case
I'd like to have the correctly persisted values as return value of the service methods.
Reproduce the error
Related issues
jhipster/generator-jhipster-entity-audit#233
Suggest a Fix
JHipster Version(s)
8.1.0
JHipster configuration
Entity configuration(s)
entityName.json
files generated in the.jhipster
directoryBrowsers and Operating System
The text was updated successfully, but these errors were encountered: