Thanks for the heads up, I had not noticed this PR.
We're planning an ORM release in the early afternoon - mainly as
Quarkus has the code freeze tonight and there are some bugfixes they
will need. So let's try to get all Reactive things in too - but if
they aren't ready by approx ~15h today we can do another release in a
They all seem simple enough so just push it:)
On Mon, 18 May 2020 at 11:26, Gavin King <gavin.king(a)gmail.com> wrote:
> We need to get this pull request on ORM applied ASAP, since it's
> currently blocking us from doing work.
> Gavin King
I've just renamed the repository on github.
Please update your bookmarks, scripts, git remotes and habits :)
I see github automatically activated redirects, but I don't know how
well that works.
You might want to rename your own forks as well?
sorry for the inconvenience, better soon than later!
We just published Hibernate Search 6.0.0.Beta7.
This release mainly improves sorts and aggregations on multi-valued or
nested fields, introduces dynamic index fields through field templates,
restores the index metamodel, and restores low-level Lucene settings.
It also includes an upgrade to Hibernate ORM 5.4.15.Final.
For more information, see our blog:
I have a request regarding issue: HHH-13936 "No auto transaction joining
from SessionImpl.doFlush": https://hibernate.atlassian.net/browse/HHH-13936
I logged this a month ago with a pull request containing a fix:
https://github.com/hibernate/hibernate-orm/pull/3335 (The travis
notification of a passed build apparently didn't come through.)
As far as I can tell this hasn't received any attention. I think I followed
all the correct procedures.
This issue is a major blocker for us to upgrade to Hibernate 5.
I'm now reaching out to you via the mailing list because I'm leaving this
company quite soon and basically want to resolve this last thing.
All I need is the confirmation that this fix will be accepted and available
in the next 5.4 release. Then I can go ahead and merge our hbm 5 upgrade
using a local snapshot build containing this fix.
Michiel Hendriks, MSc
☎️ +31 102900304
The work around Hibernate Reactive is coming along nicely. So has some
other work needed on the Vert.x front and Mutiny front. Now is time to
ship a first version to the community. With some of the people working
on it, I've tried to come up with a list of tasks and decisions to make.
And proposed decisions to avoid blockers.
Most communication happens on the project Pull Request, a good thing I
think. But the glue between them was missing as far as communication.
I propose we use hibernate-dev@ for this.
## The project name
There is an open PR related to the name of the project
I exchanged with Gavin and Sanne and went back and forth on it.
My preferred name _was_ `Hibernate ORM Reactive` because of the fight we
did to make `Hibernate` != `Hibernate ORM` brand wise. But we have quite
failed to convert the general public :) As a brand, `Hibernate Reactive`
is strong and catchy. The only project besides ORM that could become
reactive is Search (I don't think validator has a strong case). We
likely should swallow our pride and call the project `Hibernate
Reactive`. If HSEARCH reactive comes up, we could use `Hibernate
So unless someone is strongly against it, let's call it `Hibernate
Reactive` which would be our sub umbrella for our reactive work.
Frankly, the other names were too incorrect or suck for a brand. There
is also the strong possibility that we would want to deliver all
Hibernate Reactive subprojects as one to be able to combine them.
That means renaming the doc and the package, the GitHub repository and
the Quarkus Extension. This will only be done after Query support is
initially pushed not to disrupt things too much.
## Query support
I strongly think that we need Query support for the initial release. It
can be an initial Query support. But we need something. This is the one
technical subject that prevents us from releasing Hibernate Reactive
alpha. Davide is working on it and we will know more in a week or two
about the viability status.
As soon as there is shared code (working or not), Gavin offered to help.
Mutiny will be a first class API for Hibernate Reactive. Gavin is
working on building it.
## One module to rule them all
Today we have an API module and an Impl module. But reality is we don't
know how we will split the project if any. This highly depend on the API
reaction and popularity.
With Mutiny coming in, the API module became a bit complicated.
Gavin proposed to merge everything in one module during the alpha / beta
stage of the project and reevaluate with user feedback. This will only
be done after Query support is initially pushed not to disrupt things
## Quarkus extension
Andy did an awesome work into fleshing out the initial Quarkus
Extension. Even better, it works for native for the main path :)
The main annoyance is that to generate schema, you need a JDBC driver
setting and a JDBC driver in your classpath. We can improve on that but
that's not a trivial amount of work to adapt `SchemaExport` and friends.
Right now we have the readme as documentation. The proposed idea is as
- we convert the readme content (or get inspired from it) and generate a
Quarkus guide out of it. Their format are really similar.
- best would be to convert the [Quarkus Hibernate ORM
to use Hibernate Reactive and base the guide on it.
- a more formal documentation and working for Hibernate Reactive
standalone (outside of Quarkus) can grow from these. See website
We need to work on a blog announcing the project.
We need to adapt hibernate.org to have a Hibernate Reactive project.
Once you make Awestruct work, it should be a relatively quick change to
add the relevant sections. There is likely quite some work on the
various messages and content of the key sections.
Once we have all or most of this, we can release and get user feedback
When? To that, I'd quote a wise man from the future
**Lt. Commander Geordi La Forge:** Look, Mr. Scott, I'd love to explain
everything to you, but the Captain wants this spectrographic analysis
done by 1300 hours.
[La Forge goes back to work; Scotty follows slowly]
**Scotty:** Do you mind a little advice? Starfleet captains are like
children. They want everything right now and they want it their way. But
the secret is to give them only what they need, not what they want.
**Lt. Commander Geordi La Forge:** Yeah, well, I told the Captain I'd
have this analysis done in an hour.
**Scotty:** How long will it really take?
**Lt. Commander Geordi La Forge:** An hour!
**Scotty:** Oh, you didn't tell him how long it would really take, did
**Lt. Commander Geordi La Forge:** Well, of course I did.
**Scotty:** Oh, laddie. You've got a lot to learn if you want people to
think of you as a miracle worker.
in previous emails I mentioned I suggested to release a JPA3
compatible version of Hibernate ORM out soon, as I expected this to be
the natural way forward, and soon to be needed by other projects such
as WildFly. I had started working on this myself.
However, the WildFly team hasn't decided if/when they will adopt the
new Jakarta EE APIs, and I've been advised by many that this upgrade
is unlikely to be in high demand:
it brings no new benefits at all, while it introduces quite some
annoying breaking changes.
We have a fairly complete prototype in the draft PR I've sent here:
And yet, I think I'll "put it in the freezer". Unfortunately I had
already merged some preparations work in 5.5, such as upgrading to
Validator 7.x: I will revert those changes, apologies for that mess
but I think it's for the best to postpone this for later.
When there will be more interest in this, it should not be too hard to
adapt the work as it's mostly strucutured in the form of replacement
scripts which should apply nicely w/o any conflict even on future