Hibernate
/
hibernate-orm
mirror of https://github.com/hibernate/hibernate-orm
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

work on migration guide and 6.0 announcement

This commit is contained in:
Steve Ebersole 2022-03-30 09:26:02 -05:00
parent 63ba1787d0
commit d8d326a76f
2 changed files with 11 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
design/working/6.0-posts.adoc
View File

@ -31,10 +31,10 @@ discussion in <<jpa>>.
Applications using Hibernate APIs will generally be bytecode and source compatible, aside 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 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>>. source compatibility; these are covered in the link:{migration-guide-url}[migration guide].
Quite a few SPI changes have changed to support many of the topics discussed here as well as in 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 the link:{migration-guide-url}[migration guide]. Many will also be the subject of the mentioned
follow-up posts. follow-up posts.
@ -47,7 +47,7 @@ for persistence, that means changing from `javax.persistence` to `jakarta.persis
for package names as well as property and hint names. for package names as well as property and hint names.
This is clearly an unfortunate and invasive change, but beyond our control. Luckily Jakarta 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 have developed a link:{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. 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 For those using Maven, you are in luck (well, within the bounds of actually using Maven) in that
@ -55,7 +55,7 @@ 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. 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. There is also a command-line form. See the link:{jakarta-transformer-url}[transformer] docs for details.
[[read-by-position]] [[read-by-position]]

8
migration-guide.adoc
View File

@ -719,7 +719,13 @@ Hibernate no longer provides built-in support for integrating itself with JACC e
// todo (6.0) - surely there are more than this... // todo (6.0) - surely there are more than this...
== Width-first fetch determination == Fetch circularity determination
As back-ground, Hibernate does understand whether a fetch is actually, truly circular. It simply
understands that while walking a fetch-graph it encounters the same table/column(s) making up a particular
foreign-key. In this case, it simply stops walking the graph any deeper.
This
Previous versions of Hibernate determined fetches using a depth-first approach, which occasionally led Previous versions of Hibernate determined fetches using a depth-first approach, which occasionally led
to odd "circularity" determination. Starting with 6.0, we now perform fetch determination using a width to odd "circularity" determination. Starting with 6.0, we now perform fetch determination using a width