When I define in @JoinColumn parametr referencedColumnName, I get exception:
java.lang.ClassCastException: Customer cannot be cast to java.io.Serializable
Problem is in class CollectionType, where is id allways rewrite. Check my comment in next code fragment //IN THIS POINT
I am not allowed to delete my own attachments here. Please ignore the first attachment and take a look at the second file I uploaded. It is based on the hibernate-orm-5 test template.
It may seem strange to use a @OneToMany annotation from A to B, as I am referring the primary key of B and it actually is a OneToOne relation. The reason is that the presence of B is optional. I may or may not have an entity in B with the id given in nonPrimaryRelationId. For Hibernate to return optional *ToOne releations as null instead of throwing an exception when accessing the field, the Hibernate proprietary @NotFound(action = NotFoundAction.IGNORE) annotation is required on the field. With this annotation, Hibernate does not support lazy loading unless build time bytecode enhancement is enabled.
Our code requires the NotFoundAction.IGNORE annotation, performance considerations require the relationship to be lazy and our build and development environment does not allow us to use build time bytecode enhancement.
A common workaround for these restrictions seem to be to map as a *ToMany relation, allowing Hibernate to inject a proxied collection, which when accessed will resolve the lazy binding and hold 0 or 1 element.
, I don't think your issue is related to the original issue. I was able to fix your issue by using the following mapping:
, I suspect your issue is related to or a duplicate of HHH-9370.
We still need a test case to reproduce your issue. You can find test templates at https://github.com/hibernate/hibernate-test-case-templates.
, please provide feedback. I'd like to remove your test case from this issue.
@Gail Badner You obviosuly have a bug in the key management routines somewhere and this bug seems to occur in different situations. This bug is now more than five years old. If removing my test case from the issue helps you to solve it, please feel free to do so.
Looking back into the history of the bug, I would in that case however assume that the bug will be left dormant for a few more years and then someone will suggest to close it, since you don't know if it still affects Hibernate 6.
It is almost 6 years since MartinM reported this issue. Asking him now for a reproducable test case is kind of strange.