Note: Bug first noticed in our code on Hibernate 5.0.10.Final.
Created a testcase on 5.2.2.Final with the exact same behavior. Testcase attached.
If
- you have a previously-persisted parent entity A with a ManyToOne list property B of not-yet-persisted entities C
- and there is no cascade-setting on B (defaults to empty list) *
- and you perform a merge on A ("entityManager.merge(A);")
you'll end up with A containing for it's property B a collection of "empty copies" of C, call them C', which are newly-constructed objects without the attribute values C had.
Obviously, this leads to problems and is an unwanted situation.
This seems to come from the `null` value on CollectionType#549
{code:java}
while ( iter.hasNext() ) {
result.add( elemType.replace( iter.next(), null, session, owner, copyCache ) );
}
{code}
combined with EntityType#352-357
{code:java}
if ( session.getContextEntityIdentifier( original ) == null &&
ForeignKeys.isTransient( associatedEntityName, original, Boolean.FALSE, session ) ) {
final Object copy = session.getEntityPersister( associatedEntityName, original )
.instantiate( null, session );
copyCache.put( original, copy );
return copy;
}
{code}
which says that if original (child object C) is unsaved then a new instantion of C should be created and returned. It seems to me like you can return 'original' in that case.
I'd expect the merge operation to have left that the list ( field B) alone and left as-is. |
|