Description
The reference documentation section for Entity State-detection Strategies states:
Spring Data JPA offers the following strategies to detect whether an entity is new or not:
- Version-Property and Id-Property inspection (default): By default Spring Data JPA inspects first if there is a Version-property of non-primitive type. If there is, the entity is considered new if the value of that property is
null. Without such a Version-property Spring Data JPA inspects the identifier property of the given entity. If the identifier property isnull, then the entity is assumed to be new. Otherwise, it is assumed to be not new.- [...]
- [...]
Option 1 is not an option for entities that use manually assigned identifiers as with those the identifier will always be non-
null. A common pattern in that scenario is to use a common base class with a transient flag defaulting to indicate a new instance and using JPA lifecycle callbacks to flip that flag on persistence operations:
The comment that "Option 1 is not an option for entities that use manually assigned identifiers" appears to be false when there is a Version property of a non-primitive type. In this case, it doesn't matter whether the ID was manually generated or not, since it's not checked in the presence of the Version property. Option 1 isn't an option for entities that use manually assigned identifiers only when there isn't a Version property.
I've seen this approach used successfully in Spring Data MongoDB, so unless there's something different about Spring Data JPA, I believe this is the same situation here.
Expected
I would expect the documentation to clarify the fact that entity state detection using option 1 works when there is a non-primitive Version property. There's a few ways to restructure the documentation to accomplish this (Split # 1 and have 4 items in total; Have 1a & 1b; change the description after the list).