Quarkus Hibernate with Panache Next

[giscus[bot]]

Quarkus Hibernate with Panache Next

Quarkus: Supersonic Subatomic Java

https://quarkus.io/blog/hibernate-panache-next/

[omasseau]

very interesting :)

[pragmasoft-ua]

Omg so even with virtual threads available we still need that reactive mess?

[yrodiere]

Given your tone I suspect I won't need to convince you, but in case others read this: you don't need to use Hibernate Reactive, you can use Hibernate Reactive. IMO Hibernate Reactive is mostly useful to integrate with an otherwise reactive application (using Kafka events or whatever). It's not a silver bullet meant to replace Hibernate ORM.

Running Hibernate ORM (blocking) has always been fine, and should be fine in virtual threads too.

EDIT: I say "should" because virtual thread compatibility will depend a lot on your particular JDBC driver. But then if your JDBC driver doesn't like virtual threads, "traditional" threads are likely fine for you.

[adampoplawski]

Hello
We actually went to prod with first project with Virtual Thread + Agroal + Postgres JDBC and for our load this works fine. Is there particular JDBC driver that you have in ming that is "not liking virtual threads"? I read some articles suggested that Agroal is better suited for VT than HikariCP but not sure about that

[yrodiere]

Popular JDBC drivers are fine nowadays AFAIK. I'd be surprised if there were still problems with Postgres.

I'd be mostly concerned with older versions of JDBC drivers, or more exotic ones -- which I don't want to name and shame, because I didn't test them recently :) But anything requiring hibernate-community-dialects is certainly uncharted territory.

EDIT: Oh, and I didn't run benchmarks to check performance of JDBC drivers on virtual threads. That might not be awesome, independently from Quarkus. But I'm sure some people are having a look, so maybe we'll have an idea at some point.

[cdhermann]

This looks like an amazing progression of Panache. Not having support for StatelessSession stopped me using Panache. I love the blessings of Quarkus doing a lot of stuff in a reactive manner under the hood. I myself struggle a bit with reactive style development.

I wonder, can I use blocking code and unmanaged entities? As far as I understand these examples, only the reactive style supports stateless sessions.

[yrodiere]

Yes, you can use any combination of blocking/reactive + Session/StatelessSession.

[cvgaviao]

What doesn't feel right to me is the need to extend PanacheEntity or PanacheRepository.

In my case we already have corporate super classes, so it almost impossible to adopt it.

It would be so much easier if it used Interfaces instead Classes like Jakarta Data's CrudRepository.

[yrodiere]

For repositories that's already the case as evidenced in the first example:

public interface Repo extends PanacheRepository<Cat> {

For entities, "mapped superinterfaces" are simply not supported by JPA as far as I know -- for attribute mapping, I mean.

A good point is that it could be useful to use PanacheRepository on a "non-panache" entity. That may already work, but I suppose if you do that, you lose the MyEntity_.repo() accessors? @FroMage would know.

EDIT: That being said, MyEntity_.repo() accessors are only a convenience, and one can simply inject the repositories using CDI.

[FroMage]

In Panache Next, you don't need superclasses for your entities. PanacheEntity is just a dummy superclass that gets your an auto-id via WithId.Long (that you can opt out of) and implements the PanacheManagedBlockingEntity interface.

So you can either opt out of supertypes entirely (but you don't get auto-id and any instance method) or you opt in to one or both :)

[FroMage]

And as @yrodiere said, for repositories there are no superclasses at all, just interfaces, none of which you even have to implement if you use @Repository or any @Find or @Query/HQL method.

[cvgaviao]

Hello @FroMage and @yrodiere, thanks for the insights.

When I referred Repositories was that I remembered the Panache one. I played with it a bit, but them moved to Hibernate/Jakarta Data only soon.
Now I see that you have followed its steps. that is good :)

About entity, most companies I have worked on last decades have a corporate library defining JPA superclasses. In the current one we have two interfaces/classes, a WithAudit and the root one which implements WithId.

We also have a corporate persistence service layer with generic methods which uses both interfaces to define behaviors... for example, we have some methods to handle master-details pattern.

So since Quarkus and Hibernate has the possibility to augment entities and generate associated classes, I think it would be possible just require an interface to be implemented by the existent entity, and then Panache would generate what is necessary to support any behavior desired for them. Wouldn't it ?

[FroMage]

As I said, you can make your entity extend the Panache class or not, and implement the panache interface or not. Up to you. Entirely optional.