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:
Maximilian Zellhofer 2023-05-02 18:31:55 +02:00 committed by Christian Beikov
parent 11982572bd
commit 64c04e24e4
1 changed files with 4 additions and 4 deletions

View File

@ -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
);
}