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 field alone and left as-is. |
|