Feat/729 refactor settings releases

[StephGit]

Fixes #729

[mburri]

Overall - good work!
I have some minor comments and we have to discuss if it makes sense to further split up some of the angular components...

[yvespp]

Editing a release that has a deployment gives a Internal Server Error (500):

10:03:00,157 SEVERE [ch.mobi.itc.mobiliar.rest.exceptions.UncaughtExceptionMapper] (default task-15) Uncaught exception in rest call: javax.persistence.OptimisticLockException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [ch.puzzle.itc.mobiliar.business.releasing.entity.ReleaseEntity#505]
...
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [ch.puzzle.itc.mobiliar.business.releasing.entity.ReleaseEntity#505]
...

How to reproduce with dev container:

1. create a new release: test1
2. create a deployment and select release test1
3. click edit on the test1 release and without changing anything click save

=> Server error
All fields of a release should be changeable.

[yvespp]

Editing a release that has a deployment gives a Internal Server Error (500):

Maybe this could be turned into an integration test? 😁

[mburri]

Editing a release that has a deployment gives a Internal Server Error (500):

10:03:00,157 SEVERE [ch.mobi.itc.mobiliar.rest.exceptions.UncaughtExceptionMapper] (default task-15) Uncaught exception in rest call: javax.persistence.OptimisticLockException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [ch.puzzle.itc.mobiliar.business.releasing.entity.ReleaseEntity#505]
...
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) : [ch.puzzle.itc.mobiliar.business.releasing.entity.ReleaseEntity#505]
...

How to reproduce with dev container:

1. create a new release: test1
2. create a deployment and select release test1
3. click edit on the test1 release and without changing anything click save

=> Server error All fields of a release should be changeable.

Reproducing the issue is much simpler:

1. Create a release
2. Edit the release (this will work the 1st time)
3. Edit the same release again (this will never work again for this release, even after page loads and refreshes and server restarts)

Hibernate tracks concurrent modifacations of entities with a version property that is annotated with @Version

For the Release entity, this property is also annotated with @JsonIgnore, that is why it never reaches the client. Since the client does not know the property, it is not sent to the backend on update. When the json request is mapped back to the entity, the missing version property is assumed to have the value 0 which is correct for the first update. Hibernate then increases the value to 1. Subsequent updates will fail because hibernate compares the two values (they should be the same) and rejects the update, since it seems to be old data.

Removing the @JsonIgnore annotation an the version property should do the trick. But the client also needs to update its state... otherwise uses have to reload the page.

[yvespp]

AFAIK we never exposed the Version in the rest entities. I believe this was handled by merging the entity back into the jpa context before persisting it.

[mburri]

AFAIK we never exposed the Version in the rest entities. I believe this was handled by merging the entity back into the jpa context before persisting it.

I've just checked all endpoints and this is true: the version property was never exposed. But, there are currently only a few endpoints that update an existing entity. I've checked them all. All of them accept a bunch of query parameters and/ or some form of a DTO. The backend then loads the entity, sets the new properties and then writes it back to the database. That's why there was never a problem with optimistic locking, and there are checks in place to prevent that different users to overwrite each others changes.

But in case of the new endpoint to edit releases, it's indeed the version property that prevents the entity being merged back into to the jpa context - that is when hibernate compares the property and throws the StaleObjectStateExcpetion in this case.

I strongly recommend to pass the version property to the frontend (and then send it back with the PUT request) in order to prevent users overwriting each others changes. Even if there are only a few users that use the application and they are infrequently creating or updating releases.

[StephGit]

I quickly tested the current jsf implementation without exposing the version property. If two users edit the same entity the update fails for one user throwing javax.ejb.EJBTransactionRolledbackException: Row was updated or deleted by another transaction.

[yvespp]

I quickly tested the current jsf implementation without exposing the version property. If two users edit the same entity the update fails for one user throwing javax.ejb.EJBTransactionRolledbackException: Row was updated or deleted by another transaction.

This is probably because JSF is stateful and keeps the entity with the version in the session?
I don't know what the best practises are with rest but something like the version or timestamp of the last modification seems to be needed.

[StephGit]

I added the version in the frontend and wrapped the exception in a ConcurrentModificationException

[yvespp]

Tested and works as expected, you can merge when ready