Should we improve Panache 2 naming?

[gsmet]

I mentioned it in my late review of the pull request but I think the naming scheme we chose for Panache 2 is extremely confusing for users and that we should adjust it before we push CR1.

From a user perspective, Panache 1 has:

• a guide named Simplified Hibernate ORM with Panache
• an extension named quarkus-hibernate-orm-panache

For Panache 2:

• a guide named Simplified Hibernate with Panache
• an extension named quarkus-hibernate-panache

It's very unclear what you should use, and I'm pretty sure it's also going to be very confusing on code.quarkus.io. It's also not in line with all the other extensions clearly mentioning orm (vs search or validator).

Even if not pretty, I think we should keep the original artifact names and add a 2 suffix and market it as Panache 2, to make it clear that it's an evolution and people with new projects. The intent is a lot more obvious IMHO.

We should also have a clear introduction in both guides with cross references.

/cc @FroMage @yrodiere @cescoffier @geoand

[yrodiere]

Taking a step back, my personal opinion is that we should take this opportunity to rename the whole thing to "Quarkus Data". It's certainly a much dumber name than "Panache", but it's also much easier to grasp for newcomers, especially when Jakarta Data becomes a much greater part of this extension.

Now, that doesn't solve your specific problem, which is the fact that @FroMage had to name the extension quarkus-hibernate-panache because it's one extension for both ORM and Reactive (hence quarkus-hibernate-orm-panache wouldn't work).

I personally would pick quarkus-data-hibernate-orm and be done with it -- Hibernate Reactive users can just have some entry in the documentation telling them to use that.

[geoand]

Indeed, I just wanted to bring up my experience as Yoann touched on the issue.

[Sanne]

BTW I don't like "quarkus-data" because we'll most likely always have more "data related things" than what Panache can address, and also because we shouldn't imply that one needs to use Panache to access data. Also, there's possibly other things we could do "with more Panache" beyond Data. In conclusion, it's neither a subset nor a superset, it's just not matching this connotation.

[geoand]

That doesn't matter IMO. What matters IMO is eliminating one more source of confusion (we created a ton of those over the years, in all areas)

[yrodiere]

I mean if we go with quarkus-data-hibernate-orm, Panache does not need to be a superset or a subset of "all things data". We just need to make sure every quarkus-data module follows similar conventions. Which is very much what Panache is trying to do, judging from past experience with e.g. MongoDB.

[yrodiere]

Also, this needs to be put in broader context:

• MongoDB providing a Hibernate ORM dialect, enabling a (future) "Mongo with Panache" / Quarkus Data MongoDB based on Hibernate ORM
• Jakarta Data being about more than just Hibernate ORM
• Quarkus missing an alternative to Spring Data JDBC, which we could base on Jakarta Data, using Hibernate ORM / Panache or not.

[geoand]

Taking a step back, my personal opinion is that we should take this opportunity to rename the whole thing to "Quarkus Data".

+100. That's what I was going to suggest

[Sanne]

I quite like the new name, it's explained in the very first paragraph of the blog and I thought that made sense.

Since the new module is about "adding some Panache" to the Hibernate modules - all of them - it's a good name.
I think the new pattern is extensible, and it's possibly open to also automatically generate some sweet integrations for Search and other Hibernate things, letting the user pick and choose in their code via interfaces rather than having to go back-and-forth into the build tool to figure out which other extensions one needs to add.

If it's very extensible, I guess one could simply call it "Panache", and the module would add some panache to the Hibernate use and not necessarily stopping at Hibernate.

[FroMage]

So, how do we rename the entity and repository types then? Keep PanacheEntity and PanacheRepository or rename to QuarkusEntity, QuarkusRepository or what?

In the next version of JPA (which is not called that anymore), @gavinking settled for EntityAgent for the equivalent of EntityManager which manages handles stateless entities. So, I'm not sure what the adjective is for agent, when we're talking about entities. The other kind is ManagedEntity which we can use. We can't use Entity because that's their annotation. AgentedEntity doesn't feel correct English. StatelessEntity is free, though. So is RockstarEntity since we're talking about agents…

[yrodiere]

@gavinking settled for EntityAgent

That is not settled, it can still change.

So, how do we rename the entity and repository types then? Keep PanacheEntity and PanacheRepository or rename to QuarkusEntity, QuarkusRepository or what?

We could sidestep the problem and go with StandardEntity, BaseEntity or similar wording. StandardEntity.Managed.WithLongId and so on. Not great, not terrible.

[FroMage]

ManagedEntity/ManagedEntity.Reactive, StatelessEntity (or ActiveRecord since that one we could argue is an active record)/StatelessEntity.Reactive… Just throwing names out there.

[FroMage]

I like StandardEntity, I think it goes in the same list as NormalEntity, AbnormalEntity and DeviantEntity or SpecialEntity 🤣

[FroMage]

RareEntity and the DEV UI will have a pokemon appear if we get them all in the same app.

[cescoffier]

I wouldn't go with "Quarkus Data" for this specific scope.

I definitely agree that we need a "Quarkus Data" umbrella at some point—and soon—but I view that as much more global than just Panache (encompassing other data stores like Redis and Mongo, as Emmanuel mentioned).

I’m also in favor of keeping "Panache". It has really become its own brand and is strongly associated with Quarkus at this point.

Regarding the artifact naming (and whether strictly to include orm or not), I don't have a strong opinion. generally speaking, I would keep it as close to the current naming as possible.

[cescoffier]

Except that Quarkus Data as defined here is neither Spring Data, nor a Spring Data alternative - it's something different. So, they may think they understand what your are talking about, but no (basically, it is likely going to create confusion).

Also, I may be missing something, but, according to https://quarkus.io/blog/hibernate-panache-next/, there are still a lot of Panache in the code.

[FroMage]

Also, I may be missing something, but, according to https://quarkus.io/blog/hibernate-panache-next/, there are still a lot of Panache in the code.

There are, yes, but that's a technicality, we can change that when we agree on naming.

[yrodiere]

Except that Quarkus Data as defined here is neither Spring Data, nor a Spring Data alternative - it's something different. So, they may think they understand what your are talking about, but no (basically, it is likely going to create confusion).

In its current form, Panache next is very much an alternative to Spring Data JPA. So yes, naming these artifacts quarkus-data-hibernate-ormvery much makes sense and is not misleading in any way.

[cescoffier]

Well, that would mean committing to provide the rest of the ecosystem (Mongo, Redis...) and it uses "quarkus data" for something I envisioned bigger (in the sense bigger umbrella)

[yrodiere]

Well, that would mean committing to provide the rest of the ecosystem (Mongo, Redis...) and it uses "quarkus data" for something I envisioned bigger (in the sense bigger umbrella)

What a nice idea... 🤔

[marko-bekhta]

hey 👋🏻 🙂

to add another alternative -- what if we do not name it at all ? Since this version of the extension relies on repositories generated by the Hibernate ORM's annotation processor, and we can technically do that already from the Hibernate ORM extension (use the processor https://quarkus.io/guides/hibernate-orm#jakarta-data-2), how about we just move it into the Hibernate ORM extension itself ? And maybe rename the panache entity into something like an active record entity to be clear about what it is.

[FroMage]

That could be an option, but I believe we originally wanted to distinguish "traditional" JPA from this. I'm not sure how this would be documented, in terms of recommendation from the ORM docs: ORM is JPA-centric, while Panache is strongly opinionated in a slightly different way. It could work, but not sure how to position the message.

Technically, we'd have an optional dependency on HR that might be a bit annoying to resolve, but not necessarily impossible.

And maybe rename the panache entity into something like an active record entity to be clear about what it is

A lot of people think Panache Entities are "active records" because I got convinced that we should name it that in the docs, but really they're not. They're just regular JPA entities with extra instance methods. They're still definitely absolutely Hibernate entities at the core and they don't come with any behaviour that differs from them.

Adding:

public default void persist() {
 getEntityManager().persist(this);
}

To a hibernate entity does not make it an active record.

[FroMage]

Pity there appears to be no way to attach a discussion to the WG board :-/

[FroMage]

Hahaha

[cescoffier]

@FroMage Yes... You can create a "task" with the link to the discussion.

[FroMage]

Hold on… what's a "task"? All I can do is add "items" which are really issues.

[cescoffier]

Items -> Draft (Yes... weird). I created one.

[FroMage]

Thanks.

[gsmet]

BTW to clarify my intent about this discussion: I just want us to resolve the fact that the current naming is extremely confusing as you have no way to differentiate Panache 1 from Panache 2 and it's going to be a real issue when people are looking for the extension or the doc of the extension.

And for support issues too.

[marko-bekhta]

should we add some visual marker to the "experimental" extensions when they show up in the search results

That happens automatically if the extension is marked as experimental in its metadata

hmm I'm not sure that https://github.com/quarkusio/search.quarkus.io is aware of this 😔,
from what I found so far it's only visible on the guide page itself (e.g. here: https://quarkus.io/guides/aws-lambda-http but not here: https://quarkus.io/guides/#q=AWS+Lambda+with+Quarkus+REST )

to clarify 🙂 I was thinking of something like:

[FroMage]

That's a good point. And honestly, I did not find the warning very visible in https://quarkus.io/guides/aws-lambda-http either, I had to scan the entire page several times before starting to read it to see it. It could certainly be made more visual, via a tag as you showed in the search results.

[gsmet]

We could rename it to quarkus-hibernate-panache-experimental for the last case of ambiguity in the pom.xml?

I would rather use -next similar to what we did with WebSockets.next. It being experimental is just a transient status. But that's not my decision to make.

It might go out of the experimental status while we still have the Panache 1 extension around.

I think we need to make a decision soon though. @cescoffier what would be your preference?

[geoand]

I would rather use -next similar to what we did with WebSockets.next.

That's an excellent idea IMHO

[mkouba]

The only problem with -next is that you do not expect another major change 😉.