Skip to content
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

Support for Hibernate ORM 5.3 [SPR-16303] #20850

Closed
spring-projects-issues opened this issue Dec 14, 2017 · 5 comments
Closed

Support for Hibernate ORM 5.3 [SPR-16303] #20850

spring-projects-issues opened this issue Dec 14, 2017 · 5 comments
Assignees
Labels
in: data type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Dec 14, 2017

Juergen Hoeller opened SPR-16303 and commented

Hibernate ORM 5.3 is currently in preparation, finally supporting JPA 2.2. Let's pick it up for our Spring Framework 5.1 release for some deeper integration (e.g. #20852), while continuing Hibernate ORM 5.0-5.2 support at runtime (not least of it all for compatibility with WildFly 10/11 and JBoss EAP 7.0/7.1).


Issue Links:

  • #20852 Support Hibernate 5.3's ManagedBeanRegistry for dependency injection ("depends on")
  • #22049 Upgrade to Hibernate ORM 5.4 ("is depended on by")
  • #18899 Support for Hibernate ORM 5.2
  • #18061 Compatibility with Bean Validation 2.0 and JPA 2.2
  • #20425 Compatibility with EclipseLink 2.7
  • #21226 Upgrade framework build to JPA 2.2 and JTA 1.3
  • #21540 LocalSessionFactoryBean and HibernateTransactionManager for JPA EntityManagerFactory setup
  • #20972 Deprecate outdated HibernateTemplate operations in favor of lambdas
  • #21111 ClassUtils.getUserClass should support ByteBuddy-generated proxies (e.g. from Hibernate 5.3)
  • #21494 Propagate read-only status to Hibernate Session through setDefaultReadOnly

Referenced from: commits e0ccbcb

3 votes, 9 watchers

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 28, 2018

Manuel Dominguez Sarmiento commented

Works needs to be done in HibernateTemplate and possibly other classes due to the following:

Remove support for legacy HQL-style positional parameters
https://hibernate.atlassian.net/browse/HHH-12101

The main issue is that "classic HQL" positional parameters were 0-based, while JPA/JPQL-style ordinal parameters are 1-based.
"Classic HQL" positional parameter support is being removed in Hibernate 5.3.0, while HibernateTemplate is designed to be used with either 0-based positional parameters or named parameters, but apparently there is no support for 1-based ordinal parameters.

Related Hibernate issues:

Deprecate HQL-specific (JDBC-style) positional parameters
https://hibernate.atlassian.net/browse/HHH-7023

Positional parameters report position as name
https://hibernate.atlassian.net/browse/HHH-12116

This can be worked around by exclusively using named parameters (instead of either positional or ordinal), however, some HibernateTemplate methods, such as bulkUpdate() do not currently support named parameters.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 28, 2018

Juergen Hoeller commented

With respect to HibernateTemplate and in particular the specific data access operations on it, we're primarily keeping that class around for a smooth upgrade path from older Spring-Hibernate applications. For new application setups, we highly recommend direct Hibernate Session usage via SessionFactory.getCurrentSession() or - on Java 8 - possibly HibernateTemplate.execute usage with a SessionCallback implemented as a nested lambda expression.

As a consequence, for any specific HibernateTemplate operations that turn out to be incompatible with Hibernate 5.3, we'd deprecate them on our end in favor of HibernateTemplate.execute usage as outlined above. We are not aiming for completeness of those operations in any case; quite on the contrary, we'd rather reduce them to common conveniences. bulkUpdate seems to be a fine case for such replacement with execute and a Session-based lambda.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 28, 2018

Manuel Dominguez Sarmiento commented

I understand. However the main issue is that deprecation will not suffice. Code that works in Spring 5.0 + Hibernate 5.2 will cease to work at all when migrating to Spring 5.1 + Hibernate 5.3. We have a very significant codebase we need to maintain (as I'm sure it happens with many other projects that have extensively made use of HibernateTemplate over the years) and it would be useful for the code to continue working without massive recoding.

HibernateTemplate could detect whether the HQL query contains either positional (0-based, "?" style) or ordinal (1-based, "?1" style) parameters. Simple regex parsing can do this easily (no need for complex grammar analysis). Based on this, calls to Query.setParameter(index, value) and similar methods could add 1 to the parameter index if necessary. This should also be backward compatible with Hibernate 5.2 since ordinal ?1 style parameters have been supported for many years now, since Hibernate increasingly aligned with the standard JPA spec.

I agree that HibernateTemplate should probably be deprecated going forward, but a minor release (either Spring or Hibernate) should not stop solid ORM code from working, at least not without some clear and simple upgrade path.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 28, 2018

Juergen Hoeller commented

I'm afraid we won't be going to the extent of analyzing and/or manipulating user-specified HQL queries, not even for 'simple' regex replacements. This is potentially a deep hole in terms of follow-up bugs and a line that we never crossed before. We can keep existing HibernateTemplate code working as long as the underlying Hibernate version supports it... but as far as I'm concerned, we won't be extending our semi-deprecated HibernateTemplate to a new positional parameter style at this late point.

Fundamentally, the outright removal of the legacy HQL positional parameter style is an aggressive step for a minor release in Hibernate itself. I suppose this means that legacy "?" placeholders won't work at all anymore? So it's not just about adapting the parameter index in Query.setParameter calls, it's also about redefining the queries with "?1" style parameters? Since this is equally true for native Session based code and HibernateTemplate based code, I don't see why this should be worked around on our end.

Frankly, I'd rather recommend continued use of Hibernate ORM 5.2.x with Spring Framework 5.1. We'll keep supporting Hibernate ORM 5.0-5.3 at runtime anyway, so we'll allow for selective upgrading to Spring Framework 5.x while keeping your existing Hibernate version.

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 15, 2018

Juergen Hoeller commented

Our build is upgraded to Hibernate ORM 5.3 final now; everything looks fine so far. Deeper integration with its new SPIs is still pending.

@spring-projects-issues spring-projects-issues added in: data type: enhancement labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.1 RC1 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants