-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Upgrade to Hibernate 6.2.0 #2899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Thanks for the contribution. Note that dependency updates are usually something we have to do ourselves, as we have to coordinate with the downstream portfolio regarding their plans to upgrade, too. For reference for others: also note that you can already use Hibernate 6.2 with an existing boot application by simply configuring |
@odrotbohm I think this issue needs to be tagged with milestone (3.1 RC1 (2023.0.0)), right? |
We're not done yet. There are a couple of tests failing after the upgrade. Investigating. |
Hibernate 6.2 needs to be declared before Eclipselink as the latter pulls in JPA 3.0 but the former now strongly requires 3.1. Related tickets: #2899.
Avoid Hibernate debug logging to leak out of MetaAnnotatedQueryMethodHibernateIntegrationTests. Related ticket #2899.
…Hibernate and Eclipselink independently. Ticket: #2899.
…Hibernate and Eclipselink independently. Ticket: #2899.
…Hibernate and Eclipselink independently. Ticket: #2899.
Avoid Hibernate debug logging to leak out of MetaAnnotatedQueryMethodHibernateIntegrationTests. Related ticket #2899.
Upgrade Postgres to 10 for stored procedure related tests. Move off deprecated Hibernate Postgres 9.1 dialect. Switch order of persistence provider dependencies. Hibernate 6.2 needs to be declared before Eclipselink as the latter pulls in JPA 3.0 but the former now strongly requires 3.1. Related tickets: #2899.
The upgrade to Hibernate 6.2 causes its proxy generation strategy to differ depending on execution context. We previously used a lazy many-to-one relationship to verify our proxy identifier logic as that relationship reliably resulted in a proxy instance being created on versions < 6.2. It looks like some optimizations in Hibernate [0] now cause it "optimize" the proxy away. I wasn't able to figure out the exact circumstances of that optimization but our tests running on CI reliably didn't see a proxy returned while local, standalone executions did. We now simply obtain a proxy through EntityManager.getReference(…) and verify that the identifier is still accessible, dropping the addition check for a non-initialization. [0] https://hibernate.atlassian.net/browse/HHH-15790 Related ticket: #2899.
This is blocked as we cannot get the test case checking that our identifier access code does not initialize Hibernate proxies to run reliably. It works locally, it doesn't on CI. It looks like Hibernate under some circumstances optimizes the proxies away (likely nice for users) but we unfortunately reliably need to get one to perform the test. I've reached out to the Hibernate team for advice. |
Upgrade Postgres to 10 for stored procedure related tests. Move off deprecated Hibernate Postgres 9.1 dialect. Switch order of persistence provider dependencies. Hibernate 6.2 needs to be declared before Eclipselink as the latter pulls in JPA 3.0 but the former now strongly requires 3.1. Related tickets: #2899.
On Hibernate 6.2 these tests run into class loading problems on CI (likely related to [0]). Cleanup is tracked in #2911. Related ticket: #2899. [0 https://hibernate.atlassian.net/browse/HHH-15790]
Upgrade Postgres to 10 for stored procedure related tests. Move off deprecated Hibernate Postgres 9.1 dialect. Switch order of persistence provider dependencies. Hibernate 6.2 needs to be declared before Eclipselink as the latter pulls in JPA 3.0 but the former now strongly requires 3.1. Related tickets: #2899.
Under still to clarify circumstances a class processed by Hibernate might result in proxies *not* created for a otherwise proxied relationship. So far, our tests have relied on those cases always return a proxy reliably but some optimizations in Hibernate 6.2 (likely [0]) don't allow creating proxies reliably. Until we find a better way to reliably create a proxy we back off from strictly checking whether we deal with a proxy. Related tickets: #2899. [0] https://hibernate.atlassian.net/browse/HHH-15790
On Hibernate 6.2 these tests run into class loading problems on CI (likely related to [0]). Cleanup is tracked in #2911. Related ticket: #2899. [0 https://hibernate.atlassian.net/browse/HHH-15790]
Move off deprecated Hibernate Postgres 9.1 dialect. Switch order of persistence provider dependencies. Hibernate 6.2 needs to be declared before Eclipselink as the latter pulls in JPA 3.0 but the former now strongly requires 3.1. Related tickets: #2899.
Move off deprecated Hibernate Postgres 9.1 dialect. Switch order of persistence provider dependencies. Hibernate 6.2 needs to be declared before Eclipselink as the latter pulls in JPA 3.0 but the former now strongly requires 3.1. Related tickets: #2899.
Under still to clarify circumstances a class processed by Hibernate might result in proxies *not* created for a otherwise proxied relationship. So far, our tests have relied on those cases always return a proxy reliably but some optimizations in Hibernate 6.2 (likely [0]) don't allow creating proxies reliably. Until we find a better way to reliably create a proxy we back off from strictly checking whether we deal with a proxy. Related tickets: #2899. [0] https://hibernate.atlassian.net/browse/HHH-15790
Under still to clarify circumstances a class processed by Hibernate might result in proxies *not* created for a otherwise proxied relationship. So far, our tests have relied on those cases always return a proxy reliably but some optimizations in Hibernate 6.2 (likely [0]) don't allow creating proxies reliably. Until we find a better way to reliably create a proxy we back off from strictly checking whether we deal with a proxy. Related tickets: #2899. [0] https://hibernate.atlassian.net/browse/HHH-15790
Under still to clarify circumstances a class processed by Hibernate might result in proxies *not* created for a otherwise proxied relationship. So far, our tests have relied on those cases always return a proxy reliably but some optimizations in Hibernate 6.2 (likely [0]) don't allow creating proxies reliably. Until we find a better way to reliably create a proxy we back off from strictly checking whether we deal with a proxy. Related tickets: #2899. [0] https://hibernate.atlassian.net/browse/HHH-15790
Under still to clarify circumstances a class processed by Hibernate might result in proxies *not* created for a otherwise proxied relationship. So far, our tests have relied on those cases always return a proxy reliably but some optimizations in Hibernate 6.2 (likely [0]) don't allow creating proxies reliably. Until we find a better way to reliably create a proxy we back off from strictly checking whether we deal with a proxy. Related tickets: #2899. [0] https://hibernate.atlassian.net/browse/HHH-15790
Resolved via #2917. |
cc @odrotbohm
The text was updated successfully, but these errors were encountered: