I had a talk with Luis this morning with regard to the performance
benchmarks for 6 versus 5. He is working from 2 different benchmarks - one
simply compares parsing HQL (without executing it) and the other compares
certain operations (save/persist, load, etc). Luis, correct me if I am
wrong, but what I took away from the conversation is this:
1. For the operations benchmark the numbers for 6 were better than 5,
but within the error margin - so 6 is better-than-or-equal-to 5 here.
2. 6 was generally faster at parsing queries except for when it came to
interpreting paths. We need to address the paths problem, for sure, but
honestly I was not expecting any performance improvements in query parsing
- at least not initially and the primary focus of the work is in making the
executions more performant. Any improvements on query parsing performance
is cake at this point, though certainly something we want to look at.
I asked Luis to compare the numbers specifically for load operations in
that operations benchmark. That is really the only operations case where I
would expect perf improvements at this time - it should piggy-back on the
overall JDBC execution performance improvements.
Luis, I'd also like to get some simple HQL queries into that operations
benchmark if we could to verify that this ^^ happens there as well. I can
help with that if you want - let me know.
Barring any crazy outcomes from these new benchmark results, I feel
comfortable starting to plan an initial Alpha release schedule. We
currently have a fairly aggressive set of items to complete on our Alpha1
checklist. I think we ought to consider paring that down in the
interest of release early, release often - having releases would help OGM,
etc integrate early and often as well. My proposal is to just implement
basic support for plural attributes in Alpha1 and push the rest to later
1. plural attribute suppport
1. Any / ManyToAny support
1. Metamodel fetching
2. JDBC batching
4. We'll see where we are...
IMO each Alpha ought to be 2 weeks, though I could live with 3 or
depending one everyone else's opinion.
 That list is somewhat out of date anyway as quite a few things listed
there are already implemented
She held suggestions to turn better the Hibernate documentation.
From: Antônio Diego da Luz Silva <diego-luz(a)live.com>
Sent: Tuesday, July 10, 2018 5:33:20 PM
To: Vlad Mihalcea
Subject: Re: [hibernate-dev] Test
Thanks for the answer.
I sended one message before that and I haven't received answers.
From: Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
Sent: Tuesday, July 10, 2018 5:28:53 PM
To: Antônio Diego da Luz Silva
Subject: Re: [hibernate-dev] Test
Yes, we got your email.
On Tue, 10 Jul 2018, 23:22 Antônio Diego da Luz Silva, <diego-luz(a)live.com<mailto:email@example.com>> wrote:
Are someone receiving my messages?
hibernate-dev mailing list
We would like to update WildFly (14) to Javassist 3.23.1, has anyone
tried using Javassist 3.23.1 with Hibernate ORM 5.3? I'd like to know
that we at least can pass the Javassist tests with the ORM testsuite,
preferably on JDK11 (since that is why we want to upgrade Javassist on
When HHH-12054 was fixed (see
https://github.com/hibernate/hibernate-orm/pull/2042/files), we took into
account the fact that original and target could be set to
LazyPropertyInitializer.UNFETCHED_PROPERTY in the
AbstractStandardBasicType#getReplacement() method whereas we haven't
changed the prototype of the method.
Meaning we expect for instance LazyPropertyInitializer.UNFETCHED_PROPERTY
to be a T, which is not the case.
This led to ClassCastException such as in
https://hibernate.atlassian.net/browse/HHH-12555 . To be honest, I'm
wondering why we don't have more of them.
We have 2 ways of fixing this issue:
1- change the getReplacement() prototype to take Object parameters and
return an Object as the originating replace() method
2- move the LazyPropertyInitializer.UNFETCHED_PROPERTY logic up to
replace() and make getReplacement() a "I'm sure everything is OK, now get
me a clone of my original object" thing.
1- will obviously break compatibility with any user type extending
AbstractStandardBasicType#getReplacement(). 2- will slightly change the
meaning of replace() and getReplacement() and might lead to subtle behavior
changes in user applications.
2- also means that we would have to override both replace() and
getReplacement() in BlobType and allegates.
I pushed a commit for 1- at
so that you can fully grasp the issue.
Not saying it's the path we should take.
I think that will be good if it haves the advise of the need of put the cascade parameter on associations to cause the saving cascade effects on the child entitys.
Also, I think that will be good if it haves too the advise of the need of maps the entities which are subclasses of entities to use them.
Also, the orphanRemoval parameter not worked without the parent entity update operation with Hibernate native apis. This seems to be unlike that that is on Documentation.
So I did an ORM release for the first time today. All in all, the process
is very clear and precise, thanks for taking the time to document it and
Here are the issues I had. Thought you should be aware of the changes I
made (I haven't fixed issue 2/ as I'm not sure it's legit).
== 1/ Bintray Gradle plugin issue
I had a few issues with Bintray though. The first run failed with:
> Could not upload to '
org/hibernate/value: hibernate-agroal/value: 5.3.2.Final/value:
hibernate-agroal-value: 5.3.2.Final.pom': HTTP/1.1 400 Bad Request
[message:Unable to upload files: Maven group, artifact or version defined
in the pom file do not match the file path 'value: org/hibernate/value:
hibernate-agroal/value: 5.3.2.Final/value: hibernate-agroal-value:
I found https://github.com/bintray/gradle-bintray-plugin/issues/88 advising
to update the Bintray Gradle plugin so that's what I did.
It fixed the issue but apparently, the first attemps uploaded a weird
artifact named "value: org/hibernate/value: hibernate-agroal/value:
5.3.2.Final/value: hibernate-agroal-value: 5.3.2.Final.pom". Sanne removed
== 2/ Tests running
As the first attempt was messy, I ran the second attempt with:
./gradlew clean release
It did the following:
- build the artifacts
- push them to Bintray
- run the tests
This is weird IMHO. Running the tests before pushing to Bintray could be
understandable but I find it weird they are run after the push.
Not very familiar with the build so just reporting it in case it would be
considered an issue.
== 3/ Super huge SourceForge archives
The archives on SourceForge were 350MB+ (thanks to Andrea for noticing it):
apparently, when working with Eclipse, some files end up in **/bin/
folders. While it's present in the .gitignore, it wasn't present in the
exclusions of the distribution. I added them.
I also had a ./build folder containing old WildFly releases. As it's added
to the .gitignore, I also excluded it from the build.
On Hibernate ORM we're currently having "master" branch essentially
being a maintenance branch, aka master today is what's planned to be
version 5.3.2.Final in some days, 5.3.3 later, etc..
This is quite unusual, and it begs some extra attention: normally we'd
start a new minor in master, so that PRs of any kind could be welcome
in master, while specific, cherry-picked fixes are backported to the
last maintained minors.
This is not the case now and until we move on to a new minor or major
we'll need to be particularly careful about what is allowed to be
I'm not pointing fingers to any specific commit, my concern is just
raised by the high volume of changes being merged. They all look great
individually but changes are not good at this point :)
Not sure what to suggest to people wanting to contribute new features
today; maybe hold as we assume the 6.0 work will be merged in master
soon? Will be hard to say no to many reasonable requests though.
Steve, do you think that the 6.0 merge could happen soon enough to not
need any process changes in how we deal with master?