Set of value objects with primary key and composite user type causes GenericJDBCException with index out of range
Description
First goes mappings, logs, code etc. Below find lyric description.
Mapping:
Assume that there is entity that contains two value objects in the set, and the code tries to remove one of them:
This will cause an exception that is attached, but most important part is:
and the log is:
What happens? Well it seems that there is some kind of bug in handling CompositeUserType. Hibernate tries to delete given Value Object. Normally, if there are no not-null properties in the composite-element everything goes fine - Hibernate runs following query:
However when any field is marked as not-null this causes creation of primary key. Lets assume that field id in composite-element is marked not-null. This should result in following SQL:
And it does. The problem is that Hibernate still tries to bind values of address property, despite it does not belong to primary key. As they are not expected (only FKentity and id are expected) this causes index out of range exception, as there is no third parameter, so there is no parameter to bind to.
Workaround: Mark all properties in composite-element as not-null="false".
Other facts: 1. when no CompositeUserType is used everything works fine 2. when UserType is used everything works fine as well 3. CompositeUserType used in entity works fine
Attachments
1
Activity
Christian BeikovJanuary 21, 2025 at 2:25 PM
Not a problem anymore on ORM 6
RafałFMarch 3, 2020 at 11:26 PM
Just verified - problem still exists in 5.1.16 and 5.1.17. I don't have easy way to check it on higher versions of Hibernate.
Steve EbersoleOctober 28, 2015 at 3:24 AM
As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.
Steve EbersoleOctober 27, 2015 at 7:16 PM
This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.
First goes mappings, logs, code etc. Below find lyric description.
Mapping:
Assume that there is entity that contains two value objects in the set, and the code tries to remove one of them:
This will cause an exception that is attached, but most important part is:
and the log is:
What happens? Well it seems that there is some kind of bug in handling CompositeUserType. Hibernate tries to delete given Value Object. Normally, if there are no not-null properties in the composite-element everything goes fine - Hibernate runs following query:
However when any field is marked as not-null this causes creation of primary key. Lets assume that field
idin composite-element is marked not-null. This should result in following SQL:And it does. The problem is that Hibernate still tries to bind values of
addressproperty, despite it does not belong to primary key. As they are not expected (only FKentity and id are expected) this causes index out of range exception, as there is no third parameter, so there is no parameter to bind to.Workaround: Mark all properties in composite-element as
not-null="false".Other facts:
1. when no CompositeUserType is used everything works fine
2. when UserType is used everything works fine as well
3. CompositeUserType used in entity works fine