Hibernate-reactive: Reconsider the "Rx" Name

@emmanuelbernard WDYT?

Yeah, it was always a code name.

Well then we had better change it quick, because it's well along the way to solidifying into a real name!

I've assigned that to me. I'm going to do it at the end of the week, unless somebody has objections.

I'm going to do it at the end of the week

But what are you going to change it to?

hibernate-reactive doesn't sound too bad

>

+1 to hibernate-reactive

On Wed, Apr 1, 2020 at 7:45 AM DavideD notifications@github.com wrote:

hibernate-reactive doesn't sound too bad

>

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/hibernate/hibernate-rx/issues/77#issuecomment-607292426,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADJJTIRGWQNUSN7FC3WCSLRKNHRJANCNFSM4LX6AEVQ
.

That's fine but I don't want to type ReactiveSession a thousand times....

I like HibernateRX : being "reactive" is a concept, it's not a trademark of RxJava.

That's fine but I don't want to type ReactiveSession a thousand times.

Type? Your keyboard doesn't have a space button? :)

To be fair I don't like that much to use a prefix in a class name. Would it be enough to have in the package? Or is it too confusing when working with ORM?
Maybe we could use R as prefix?

Here's a summary of the options I could think of (feel free to suggest something different):

1. org.hibernate.rx.RxSession (current)
2. org.hibernate.rx.Session
3. org.hibernate.reactive.ReactiveSession
4. org.hibernate.reactive.Session
5. org.hibernate.reactive.RSession
6. org.hibernate.rx.RSession

Any other suggestions?

I don't have a strong preference. I think Reactive make the name more readable and it's not that long. Note that It's not necessary a prefix because for some implementation or class extending a super class it could be something like:

1. class AbstracRxtEntityPersister extends RxEntityPersister
2. class AbstracReactivetEntityPersister extends ReactiveEntityPersister

This is not very consistent in the project right now. Sometimes classes are using
RxAbstractEntityPersister

I think I will use option 3: org.hibernate.reactive.ReactiveSession
But I will wait to hear if there are better suggestions or strong opinions against it.

I would vote for 3 as well, but perhaps @vietj has an opinion too?

Yeah, I was trying to come up with a better option, but frankly I drew a blank and I agree with you guys: there doesn't seem to be anything really better than ReactiveSession.

I hate the lack of type aliases in Java. The only hack I can think of would be to have Reactive.Session, Reactive.Query, etc, as inner interfaces of some Reactive type, letting you use static imports if you want. That's a reasonable approach, but one I've never really seen anyone else use in Java.

I like options 2 and 4:

• org.hibernate.rx.Session
• org.hibernate.reactive.Session

Let the package name convey that the classes are "reactive". If we have to add Rx/Reactive as a prefix to all classes then it makes the classes seem like second-class citizens.

The main downside I see of using the same class name as the non-reactive counterparts would be if we expect users to use both classes in the same class (thus requiring fully-qualified class names everywhere types are expressed), but AFAIK that should not happen?

I like options 2 and 4:

• org.hibernate.rx.Session
• org.hibernate.reactive.Session

FTR I'm also OK with that, however, I would note that it increases the risk of error when autoimporting.

Given that we're ultimately almost certain to have multiple flavors of reactive session, I would like to propose the following:

• MutinySession for Mutiny
• StagedSession or something like that for CompletionStage
• etc

WDYT?

Is this the only user-facing API that exposes reactive type flavours?

Is this the only user-facing API that exposes reactive type flavours?

Among the "main" APIs consider the Query equivalents as well.

For the record, I believe "Rx" has a nice ring to it, and it's not _owned_ by RxJava project at all - as I mentioned above - so I'd like to keep the name as the others just don't sound right.

On the contract structure

I don't like the overloading of the Session interface, as Gavin pointed out, it leads to auto completion errors and a cognitive overload for people.

So +1 for either of the following patterns:

• MutinySession, RxJava2Session, JDKReactiveSession (for CompletionStage and Flow)
• SessionMutiny, SessionRxJava2 etc

An alternative pattern is reactiveSession.forMutiny().[...], reactiveSession.forJDK().[...] but it would make a hell of a dependency nightmare most likely. reactiveSession.unwrap(MutinySession.class) does not seem to bring value.

Some extra points:

• Rx has 3 versions non compatible so one would need to have the version number in the contract
• CompletionStage's brother in arm is Flow that's why I called it JDKReactiveSession
• RxJava has several multiple and several single types, so each RxJavaXSession method will likely be "overloaded" eg fetchAsSingle() etc

I imagine Query would also have a Reactive counterpart. BTW it occurred to me that query parameters should accept both the direct type and the reactive wrappers e.g. Uni<String>

On the name, I guess Hibernate ORM Reactive is fine hibernate-orm-reactive but @FroMage what about "Panache Rx" does it go over a similar transformation?

@emmanuelbernard note that the current way to obtain a Session and SessionFactory is:

RxSessionFactory sessionFactory = emf.unwrap(RxSessionFactory.class);
RxSession session = sessionFactory.openRxSession();

I'm fairly happy with this pattern.

JDKReactiveSession

Ugh. That looks horrible for something we're likely to see so often in code.

I imagine Query would also have a Reactive counterpart.

Yes, it's already there and it's currently called RxQuery. But it doesn't do anything for now.

Honestly, I'm increasingly liking the following option:

//I want to try out Mutiny
Mutiny.SessionFactory sessionFactory = emf.unwrap(Mutiny.SessionFactory.class);
Mutiny.Session session = sessionFactory.openReactiveSession();
Mutiny.Query = session.createQuery(hql);

or:

//I want to try it out with CompletionStage
Stage.SessionFactory sessionFactory = emf.unwrap(Stage.SessionFactory.class);
Stage.Session session = sessionFactory.openReactiveSession();
Stage.Query = session.createQuery(hql);

And then, once I know for sure I'm using Mutiny, I can just write:

import static org.hibernate.reactive.mutiny.Mutiny.*;

...

SessionFactory sessionFactory = emf.unwrap(SessionFactory.class);
Session session = sessionFactory.openReactiveSession();
Query = session.createQuery(hql);

I think the outer class substantially alleviates the problem of accidenting the auto-import. (Though it does have other disadvantages.)

that looks brilliant @gavinking

@gavinking I really like your last proposal.

I think the outer class substantially alleviates the problem of accidenting the auto-import. (Though it does have other disadvantages.)

For example?

@DavideD well one disadvantage is that IDE's don't usually automatically add static imports. (Though you can configure them to do it.)

@emmanuelbernard note that the current way to obtain a Session and SessionFactory is:

RxSessionFactory sessionFactory = emf.unwrap(RxSessionFactory.class);
RxSession session = sessionFactory.openRxSession();

I'm fairly happy with this pattern.

JDKReactiveSession

Ugh. That looks horrible for something we're likely to see so often in code.

From most of the feedback I've gathered, people hate CompletionStage and go for RxJava or friends. So that version would be the poor man's choice.

From most of the feedback I've gathered, people hate CompletionStage and go for RxJava or friends. So that version would be the poor man's choice.

Are you trying to make sure it has not a chance of being used ? :-D

From most of the feedback I've gathered, people hate CompletionStage and go for RxJava or friends. So that version would be the poor man's choice.

Sure, I hate it too.

IDE's don't usually automatically add static imports

That's a pretty strong point against it, that you can't write Session and get an IDE proposal to import static Mutiny.Session, so you always have to type it out prefixed Mutiny.Session. And all docs will have to include imports too, which makes it hard to copy/paste.

On the name, I guess Hibernate ORM Reactive is fine hibernate-orm-reactive but @FroMage what about "Panache Rx" does it go over a similar transformation?

Yes. It's always been a codename.

That's a pretty strong point against it, that you can't write Session and get an IDE proposal to import

I don't feel it's that strong: they can still write Mutiny.SessionFactory, like we probably should stick to in documentation (so we won't have to include imports, even though maybe we always should as a general rule).

@FroMage it's not that bad. In intelliJ go to Settings > Code Style > Java > Imports. In Eclipse there's something similar.

For what it's worth, Mutiny should be considered the default API in my opinion. The rest could fall under some compat package. Even the CompletionStage/Flow version :-)

Update: Given the Mutiny docs, does it even make sense to bake in compat? Just rely on Mutiny for that, and put the (rather small) burden on the developer to do the conversion if they need to convert from one to the other.

• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_completionstages
• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_rx_java_2
• https://smallrye.io/smallrye-mutiny/#_how_do_i_interact_with_reactor

Clement is adding trampolines to Mutiny, might be another supporting argument for make Mutiny default for Reactive Hibernate.

This discussion evolved on the hibernate-dev mailing list. We all seem inclined to go with Hibernate Reactive... ok?

Would be best to reply on the mailing list.

Reminder, to register see:

• https://lists.jboss.org/mailman/listinfo/hibernate-dev

Specifically this is the big thread relating to this issue (among other things):

• https://lists.jboss.org/pipermail/hibernate-dev/2020-May/018774.html

Hibernate Reactive, ok?

:champagne:

Specifically this is the big thread relating to this issue (among other things):

What big thread, there's a single email ;)

Personally I still like HibernateRX better -- I agree w/ Sanne that RxJava doesn't own "Rx" and IMO HibernateRX is a catchy name. Hibernate Reactive seems more like a description than a name. Just my $0.02 and I didn't want to clutter the mailing list thread w/ this.

Personally I still like HibernateRX better -- I agree w/ Sanne that RxJava doesn't own "Rx" and IMO HibernateRX is a catchy name. Hibernate Reactive seems more like a description than a name. Just my $0.02 and I didn't want to clutter the mailing list thread w/ this.

The problem @aguibert is that what does the x stand for in your Hibernate Rx name ?
Reactive Extension is something specific https://en.m.wikipedia.org/wiki/Reactive_extensions

right, I would think Hibernate Rx would just stand for "Hibernate Reactive Extensions". Reactive Extensions is something specific, but it refers to a concept, not a particular product or project. IMO what we are doing here still fits that concept.

Since it looks like we are as close to consensus as we will ever get with the name "Hibernate Reactive", I'm totally fine with that name too though.

I'll close this as there was no revolt as consequence from Emmanuel's email on the mailing list :)

Hibernate Reactive it is! Thanks again @murphye and all

Followed up by #111