HHH-15393: fix for what looks like a copy & paste error
In the changes added to BasicCollectionPersister during HHH-15393, it looks as if generateUpdateRowOperation has maybe been copy-pasted from generateInsertRowOperation (which is perfectly fine), but when the custom sql update row operation is generated, the mutation details for the insert case rather than the ones for the update case are fetched. In case that this assumption is correct, there are some more in buildCustomSqlUpdateRowOperation, where getDeleteDetails() is used instead of getUpdateDetails().
This commit is contained in:
parent
11982572bd
commit
64c04e24e4
|
@ -411,7 +411,7 @@ public class BasicCollectionPersister extends AbstractCollectionPersister {
|
|||
// Update handling
|
||||
|
||||
private JdbcMutationOperation generateUpdateRowOperation(MutatingTableReference tableReference) {
|
||||
if ( getIdentifierTableMapping().getInsertDetails().getCustomSql() != null ) {
|
||||
if ( getIdentifierTableMapping().getUpdateDetails().getCustomSql() != null ) {
|
||||
return buildCustomSqlUpdateRowOperation( tableReference );
|
||||
}
|
||||
|
||||
|
@ -437,9 +437,9 @@ public class BasicCollectionPersister extends AbstractCollectionPersister {
|
|||
return new JdbcUpdateMutation(
|
||||
getCollectionTableMapping(),
|
||||
this,
|
||||
getCollectionTableMapping().getDeleteDetails().getCustomSql(),
|
||||
getCollectionTableMapping().getDeleteDetails().isCallable(),
|
||||
getCollectionTableMapping().getDeleteDetails().getExpectation(),
|
||||
getCollectionTableMapping().getUpdateDetails().getCustomSql(),
|
||||
getCollectionTableMapping().getUpdateDetails().isCallable(),
|
||||
getCollectionTableMapping().getUpdateDetails().getExpectation(),
|
||||
parameterBinders
|
||||
);
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue