Merging a new entity having a @GeneratedValue id should not set the generated id to the original entity
Activity
![](https://secure.gravatar.com/avatar/61a63fed50c84da73ec134c652cdfd27?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FGK-1.png)
Gavin King March 22, 2024 at 7:28 AM
I have no idea what any of that means.
But in case there are any doubts, here’s our policy:
We sometimes fix bugs in point releases.
Also, we sometimes fix bugs in minor releases.
I’m glad we cleared that up.
Have a nice day.
Alex Nistico March 22, 2024 at 7:10 AM
that is a very weird phylosofy from your part. You would accept to introduce breaking changes in patch versions, but then fix bugs introduced by such changes into the next minor release? This “fix” introduced another bug (HHH-17730), which has been resolved but the scheduled for 4.5.0. Semantic versioning might not be a “suicide pact”, but it still a contract, if you don’t respect it, then Hibernate users will always have to upgrade with fear, even for patch versions.
![](https://secure.gravatar.com/avatar/61a63fed50c84da73ec134c652cdfd27?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FGK-1.png)
Gavin King March 6, 2024 at 5:20 AM
To be very clear about this: every single bugfix changes externally-visible behavior, and is therefore a potentially-breaking change. To adopt an ideology which says that one can never "break” in a point release is to say that one can never fix bugs in a point release. So we can just not have point releases. But of course that’s absurd.
On the other hand, if you don’t want to be impacted by bug fixes, there's an incredibly simple solution: don’t upgrade. The previous point release is still sitting there in Maven. There, FIFY.
![](https://secure.gravatar.com/avatar/61a63fed50c84da73ec134c652cdfd27?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FGK-1.png)
Gavin King March 6, 2024 at 5:13 AM
Johannes is correct. Semantic versioning is not a suicide pact.
![](https://secure.gravatar.com/avatar/25ff9d47c168977ee2ee39843b334c86?d=https%3A%2F%2Favatar-management--avatars.us-west-2.prod.public.atl-paas.net%2Finitials%2FRA-0.png)
Réda Housni Alaoui February 26, 2024 at 10:57 AM
Because I am too lazy, here is a link summing up my rationale about why I think it should have been fixed in 6.5.x instead of 6.4.x =>
Consider the following entity:
and note that the ID is of type Integer, not int.
The following test fails since Hibernate 6.2.8.Final
The JPA spec 3.2.7.1. says that merge should copy the state from the new to the new managed entity:
The emphasis of "copied" to me implies that the original new entity instance should not be modified. Admittedly it is not spelled out, but at least EclipseLink (4.0.2) agrees with my interpretation of the situation. If one were to change Integer to int, Hibenate also leaves the new entity instance's id field alone.
Therefore, I think this is a bug.