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

View File

@ -411,7 +411,7 @@ else if ( attributeMapping.getIndexDescriptor() != null ) {
// Update handling
private JdbcMutationOperation generateUpdateRowOperation(MutatingTableReference tableReference) {
if ( getIdentifierTableMapping().getInsertDetails().getCustomSql() != null ) {
if ( getIdentifierTableMapping().getUpdateDetails().getCustomSql() != null ) {
return buildCustomSqlUpdateRowOperation( tableReference );
}
@ -437,9 +437,9 @@ private JdbcMutationOperation buildCustomSqlUpdateRowOperation(MutatingTableRefe
return new JdbcUpdateMutation(
getCollectionTableMapping(),
this,
getCollectionTableMapping().getDeleteDetails().getCustomSql(),
getCollectionTableMapping().getDeleteDetails().isCallable(),
getCollectionTableMapping().getDeleteDetails().getExpectation(),
getCollectionTableMapping().getUpdateDetails().getCustomSql(),
getCollectionTableMapping().getUpdateDetails().isCallable(),
getCollectionTableMapping().getUpdateDetails().getExpectation(),
parameterBinders
);
}