From a8d9d4e5eff36436bf07882e60ec3a1c34a13226 Mon Sep 17 00:00:00 2001 From: Steve Ebersole Date: Tue, 15 Mar 2022 07:58:01 -0500 Subject: [PATCH] prep 6.0 Final announcement --- design/working/6.0-posts.adoc | 137 ++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 design/working/6.0-posts.adoc diff --git a/design/working/6.0-posts.adoc b/design/working/6.0-posts.adoc new file mode 100644 index 0000000000..016e504dfe --- /dev/null +++ b/design/working/6.0-posts.adoc @@ -0,0 +1,137 @@ += Hibernate 6.0 is Coming +Steve Ebersole +:awestruct-tags: ["Hibernate ORM"] +:awestruct-layout: blog-post +:docs-url: https://docs.jboss.org/hibernate/orm/6.0 +:migration-guide-url: {docs-url}/migration-guide/migration-guide.html +:user-guide-url: {docs-url}/userguide/html_single/Hibernate_User_Guide.html +:jakarta-transformer-url: https://github.com/eclipse/transformer + +As Hibernate ORM 6.0 approaches Final, I wanted to take a moment to look back at its origins and +driving forces; and to give insight into why certain choices were made. + +This post will be followed by a series of more focused posts targeting specific improvements or +cool new features. + + +[[api-spi]] +== APIs and SPIs + +While many things have changed in 6.0, we strove to minimize changes to APIs to help +mitigate migration costs. + +[NOTE] +==== +See https://hibernate.org/community/compatibility-policy/ for a discussion of what we consider +an API versus an SPI. +==== + +Applications which use only the Jakarta Persistence APIs will be "source compatible" within the +discussion in <>. + +Applications using Hibernate APIs will generally be bytecode and source compatible, aside +from the removal of deprecated stuff. There are a few one-off changes that break bytecode and/or +source compatibility; these are covered in the <<{migration-guide-url},migration guide>>. + +Quite a few SPI changes have changed to support many of the topics discussed here as well as in +the <<{migration-guide-url},migration guide>>. Many will also be the subject of the mentioned +follow-up posts. + + +[[jpa]] +== Jakarta Persistence + +Java Persistence has become Jakarta Persistence as part of the overall move of Java EE +to Jakarta. Various legal requirements forced the changing of the `javax` namespace - +for persistence, that means changing from `javax.persistence` to `jakarta.persistence` +for package names as well as property and hint names. + +This is clearly an unfortunate and invasive change, but beyond our control. Luckily Jakarta +have developed a <<{jakarta-transformer-url},transformer>> to help with these migrations. We actually +used this tool to migrate Hibernate's own source code. It works well-ish. + +For those using Maven, you are in luck (well, within the bounds of actually using Maven) in that +Jakarta themselves provide a Maven plugin to integrate this transformer. + +For those using Gradle, you can use the tasks we developed to transform Hibernate's source code. + +There is also a command-line form. See the <<{jakarta-transformer-url},transformer>> docs for details. + + +[[read-by-position]] +== Read-by-position + +A few years ago, around the 5.4 timeframe, we worked with the amazing performance team at Red Hat +to squeeze even more great performance out of Hibernate ORM. + +This work was part of a larger effort to improve the performance of WildFly. Ultimately, the limiting +factor to additional improvements within Hibernate was our approach of reading values from a JDBC +`ResultSet` by name rather than by position. For every JDBC driver out there, reading by name is slower. + +It quickly became obvious that minimal changes would not be enough, and so this work led to many changes. +A great analogy is to consider migrating a Map-based solution to List-based. There is the obvious impact +of changing calls to accept an `int` rather than a `String` as well as internally keeping track of the +positions of each selected value within the `ResultSet`. There is also the perhaps not-so-obvious +impact of changing the callers and consumers of those contracts to keep track of positions. + +These changes have led to improvements on a number of fronts: + +1. As mentioned, reading by position is significantly faster than reading by name which leads to +performance improvements. +2. Historically Hibernate generated SQL select queries with a defined pattern of named column aliases +which were later used to access the specific result. We've all seen these "ugly" aliases. With these +changes, those select-clause aliases are no longer needed resulting in much more readable generated +SQL. +3. Although we implemented some improved support for limiting needed joins within an entity mapping +(joined inheritance, secondary tables) in 5.x, 6.0 allows even better opportunity for this. +4. (2) and (3) combined results in much smaller SQL needing to be sent to the server which can +have an impact on network communication. Every bit helps. + +This was by far the biggest force behind 6.0 initially. + + + +[[mapping-model]] +== Mapping Model + +- Object-oriented +- More user-friendly +- Attribute order + + +[[width-first]] +== Width-first fetching + +- examples mainly + + +[[annotations]] +== Annotations + +- type-safety + + +[[hql]] +== HQL + +- poor and unmaintainable grammars + + +[[criteria]] +== Criteria + +- removal of legacy Criteria +- no longer Criteria -> HQL -> Query + + +[[sql-ast]] +== SQL as AST + +mention Dialect involvement + + +[[dialect-init]] +== Dialect initialization + +- `Dialect` constructor +- `Dialect#initializeFunctionRegistry`