Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current implementation only generates IDs for NULL values.
But in JPA or in particular Hibernate generates a new ID for all unmanaged entities (If an ID generator is used).
In Kotlin in particular, this can be exploited as follows:
The "id" field is initialized with a 0-UUID and is never NULL.
This is a popular approach, mainly because of the NULL safety in Kotlin.
In order not to change the previous behavior, there is now a KeyGenerationStrategy with which you can change the behavior:
An entity that is not yet contained in the DataStore is seen as "unmanaged".
Besides, the mock is not really complete.
When an "unmanaged" entity is saved, Hibernate usually creates a clone.
This is therefore useful in order to prevent side effects from object manipulation.
The mock does not do that, which for example leads to the following code not working (in JPA + Hibernate, however, it does):
However, a (serialized) clone should perhaps be saved in the DataStore in order to prevent manipulation in the DataStore?