HHH-18228: Fix hibernate-tool code generation (ClassNotFoundException) #8565
Conversation
|
Any feedback on this? |
|
Thanks for your pull request! This pull request appears to follow the contribution rules. › This message was automatically generated. |
Foreign keys based on compound keys run into a check for java records. But the to-be-generated classes do not exist on the classpath and therefore the check fails. `org.hibernate.mapping.Component#getComponentClass` is now used in a lazy manner
|
Hibernate doesn't seem to be dead... So the project is simply not interested in community contributions?! Would be too sad, if no solution will be implemented for that problem... |
There was a problem hiding this comment.
@fanste thank you for your contribution! Sorry for taking so long, we have a lot of issues in our backlog and we're doing our best to review pending PRs. Left a comment for you.
We're also in the process or investigating a move to the Apache Software License v2. If you agree with allowing this change to be relicensed under that license, please add this text to the subject -
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.
| // As mutable and componentClass are based on the actual component | ||
| // type, both variables must be lazily initialized in some cases. | ||
| // E.g. on code generation by hibernate-tools, the component type | ||
| // might not yet exist (compound keys), resulting in a | ||
| // ClassNotFoundException. |
There was a problem hiding this comment.
I'm not sure I fully understand this use-case: why would the component class, i.e. the class of the generated composite key, not exist while the componentClassName does not return null? Maybe the problem is we shouldn't return a class name at all, or we should resolve the class eagerly when generating the ComponentType.
Could you please include a test demonstrating the issue within your PR? This can help us understand the problem better and ensure no regressions will be introduced in the future.
There was a problem hiding this comment.
The classes are also used by the hibernate-tool project for the code generation. So the to-be-generated XXXId class is present in the DB metadata (because to a compound key) and therefore in the class model but does not yet physically exist.
There is also an active hibernate-tools issue for this: HBX-2840
But I will try to create a standalone reproducer.
There was a problem hiding this comment.
There is also an active hibernate-tools issue for this: HBX-2840
Great, hopefully Koen will be able to take a look soon and if we can identify this as a tools issue I'm sure it will be fixed. If you want, you can also try taking a look and proposing a fix, if possible.
Let us know about the test. If you don't mean to continue contributing through this PR, please close it so we can progress with cleanup in our backlog.
There was a problem hiding this comment.
I doubt it is a pure TOOLS issue, as the second-pass processing is setup and run by ORM, based on the metadata feed via TOOLS. See this line in mapping.BasicValue.
Either TOOLS is not allowed to use the classes from CORE anymore - which would be a huge pain in the a.. (i think) or this use case needs to be handled by ORM.
This commit is the root cause of this issue: 3e8056d
Reproducer is attaches as a separat comment.
|
Reproducer: https://github.com/fanste/reproducers/tree/hhh-18228 Run it using the command This should throw the following error:
Reason is the compound primary key of tblTest1 also used as a foreign key in tblTest2. The demonstrated use case is simplied to the bare minimum. |
|
Fixed by HBX-2840 / hibernate-tools#4986 |
2 participants
Foreign keys based on compound keys run into a check for java records. But the to-be-generated classes do not exist on the classpath and therefore the check fails.
Issue: https://hibernate.atlassian.net/browse/HHH-18228
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.