hypersistence-utils: PostgreSQLEnumType error "Could not set value of type" with Hibernate 6 and Quarkus Panache
We are using hypersistence-utils together with Quarkus, Kotlin, Hibernate 6 and Postgresql 15.
After migrating from quarkus 2 and hibernate 5 we now face an enum issue we hadn’t had before.
Could not set value of type [DemoEnum] : DemoEntity.demoEnum (setter)
at org.hibernate.property.access.spi.SetterFieldImpl.set(SetterFieldImpl.java:86) at org.hibernate.property.access.spi.EnhancedSetterImpl.set(EnhancedSetterImpl.java:40) at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:4155) at org.hibernate.sql.results.graph.entity.AbstractEntityInitializer.initializeEntityInstance(AbstractEntityInitializer.java:844) at org.hibernate.sql.results.graph.entity.AbstractEntityInitializer.initializeEntity(AbstractEntityInitializer.java:804) at org.hibernate.sql.results.graph.entity.AbstractEntityInitializer.initializeInstance(AbstractEntityInitializer.java:790)
We also converted the project into Java and get the same issue.
Java: https://github.com/neukunft/pg-issue-java/tree/main Kotlin: https://github.com/neukunft/pg-issue
Any suggestions highly appreceated.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 36 (14 by maintainers)
Commits related to this issue
- PostgreSQLEnumType error "Could not set value of type" with H6 and Panache #634 — committed to vladmihalcea/hypersistence-utils by vladmihalcea a year ago
- PostgreSQLEnumType error "Could not set value of type" with Hibernate 6 and Quarkus Panache #634 — committed to vladmihalcea/hypersistence-utils by vladmihalcea a year ago
FWIW forks, here is the test:
The outcome of running this test is:
P.S. I thought the test worked on Java 8 but it doesn’t because
readAllBytes()
was only added in 9. Oh well, it can be easily updated 😃Fixed.
After inspecting the
ClassUtils
in Spring, I noticed that they only cache the most common Java classes while leaving the rest uncached.Since the ones we load are very specific, the number of classes loaded via Reflection will not be very high, so the cache will probably have very little impact, even on Java 8.
@neukunft The artifact was in staging mode in Nexus and I released it now. It should be available in a couple of hours in Maven Central.
👌
That’s highly debatable (apart for the questionable performance benefit, you’re opening yourself up to potential ClassLoader leaks).
Anyway, I demonstrated the problem is clearly with the library (and of course it’s a problem that can easily happen to anyone) so up to you folks how and if you want to handle it.
Providing a test case would be the first step to validate the problem.