Hibernate-reactive: Überdenken Sie den "Rx"-Namen

@emmanuelbernard WDYT?

Ja, es war immer ein Codename.

Dann sollten wir es besser schnell ändern, denn es ist auf dem besten Weg, sich zu einem richtigen Namen zu verfestigen!

Das habe ich mir zugewiesen. Ich werde es Ende der Woche machen, es sei denn, jemand hat Einwände.

werde ich Ende der Woche machen

Aber in was willst du es ändern?

hibernate-reactive hört sich nicht schlecht an

>

+1 auf überwintern-reaktiv

Am Mi, 1. April 2020 um 7:45 Uhr schrieb DavideD [email protected] :

hibernate-reactive hört sich nicht schlecht an

>

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/hibernate/hibernate-rx/issues/77#issuecomment-607292426 ,
oder abmelden
https://github.com/notifications/unsubscribe-auth/AADJJTIRGWQNUSN7FC3WCSLRKNHRJANCNFSM4LX6AEVQ
.

Das ist in Ordnung, aber ich möchte nicht tausendmal ReactiveSession eingeben....

Ich mag HibernateRX : "reaktiv" zu sein ist ein Konzept, es ist kein Markenzeichen von RxJava.

Das ist in Ordnung, aber ich möchte nicht tausendmal ReactiveSession eingeben.

Typ? Ihre Tastatur hat keine Leertaste? :)

Um fair zu sein, mag ich es nicht so sehr, ein Präfix in einem Klassennamen zu verwenden. Wäre es genug im Paket zu haben? Oder ist die Arbeit mit ORM zu unübersichtlich?
Vielleicht könnten wir R als Präfix verwenden?

Hier ist eine Zusammenfassung der Optionen, die mir einfallen (Sie können gerne etwas anderes vorschlagen):

1. org.hibernate.rx.RxSession (aktuell)
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

Irgendwelche anderen Vorschläge?

Ich habe keine starke Präferenz. Ich denke, Reactive macht den Namen lesbarer und er ist nicht so lang. Beachten Sie, dass ein Präfix nicht erforderlich ist, da dies für einige Implementierungen oder Klassen, die eine Superklasse erweitern, etwa wie folgt lauten könnte:

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

Dies ist im Moment im Projekt nicht sehr konsistent. Manchmal verwenden Klassen
RxAbstractEntityPersister

Ich denke, ich werde Option 3 verwenden: org.hibernate.reactive.ReactiveSession
Aber ich werde warten, um zu hören, ob es bessere Vorschläge oder starke Meinungen dagegen gibt.

Ich würde auch für 3 stimmen, aber vielleicht hat @vietj auch eine Meinung?

Ja, ich habe versucht, eine bessere Option zu finden, aber ehrlich gesagt habe ich eine Lücke gezogen und ich stimme euch zu: Es scheint nichts wirklich Besseres zu geben als ReactiveSession .

Ich hasse das Fehlen von Typaliasen in Java. Der einzige Hack, den ich mir vorstellen kann, wäre, Reactive.Session , Reactive.Query usw. als innere Schnittstellen eines Typs von Reactive verwenden, sodass Sie statische Importe verwenden können, wenn Sie möchten. Das ist ein vernünftiger Ansatz, aber ich habe noch nie jemanden gesehen, der ihn in Java verwendet hat.

Ich mag Option 2 und 4:

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

Lassen Sie den Paketnamen vermitteln, dass die Klassen "reaktiv" sind. Wenn wir allen Klassen Rx/Reactive als Präfix hinzufügen müssen, erscheinen die Klassen wie Bürger zweiter Klasse.

Der Hauptnachteil, den ich bei der Verwendung des gleichen Klassennamens wie bei den nicht-reaktiven Gegenstücken sehe, wäre, wenn wir erwarten, dass Benutzer beide Klassen in derselben Klasse verwenden (und daher vollqualifizierte Klassennamen überall dort erfordern, wo Typen ausgedrückt werden), aber AFAIK sollte dies nicht tun passieren?

Ich mag Option 2 und 4:

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

FTR Ich bin auch damit einverstanden, allerdings würde ich anmerken, dass es das Fehlerrisiko beim Autoimport erhöht.

Angesichts der Tatsache, dass wir letztendlich mit ziemlicher Sicherheit mehrere Arten von reaktiven Sitzungen haben werden, möchte ich Folgendes vorschlagen:

• MutinySession für Meuterei
• StagedSession oder so ähnlich für CompletionStage
• etc

WDYT?

Ist dies die einzige benutzerorientierte API, die reaktive Typaromen verfügbar macht?

Ist dies die einzige benutzerorientierte API, die reaktive Typaromen verfügbar macht?

Betrachten Sie unter den "Haupt"-APIs auch die Query Äquivalente.

Für die Platte glaube ich, dass "Rx" einen schönen Klang hat und überhaupt nicht dem RxJava-Projekt gehört - wie ich oben erwähnt habe - also möchte ich den Namen behalten, da die anderen einfach nicht richtig klingen.

Zur Vertragsstruktur

Ich mag die Überlastung der Session Schnittstelle nicht, da sie, wie Gavin betonte, zu Fehlern bei der automatischen Vervollständigung und einer kognitiven Überlastung der Menschen führt.

Also +1 für eines der folgenden Muster:

• MutinySession , RxJava2Session , JDKReactiveSession (für Abschlussphase und Flow)
• SessionMutiny , SessionRxJava2 usw.

Ein alternatives Muster ist reactiveSession.forMutiny().[...] , reactiveSession.forJDK().[...] aber es würde höchstwahrscheinlich einen höllischen Albtraum von Abhängigkeiten machen. reactiveSession.unwrap(MutinySession.class) scheint keinen Wert zu bringen.

Einige zusätzliche Punkte:

• Rx hat 3 Versionen, die nicht kompatibel sind, daher müsste man die Versionsnummer im Vertrag haben
• CompletionStage Bruder von JDKReactiveSession
• RxJava hat mehrere multiple und mehrere einzelne Typen, daher wird jede RxJavaXSession Methode wahrscheinlich "überladen", zB fetchAsSingle() etc.

Ich stelle mir vor, dass Query auch ein reaktives Gegenstück haben würde. Übrigens ist mir aufgefallen, dass Abfrageparameter sowohl den direkten Typ als auch die reaktiven Wrapper akzeptieren sollten, z. B. Uni<String>

Was den Namen angeht , denke ich, dass Hibernate ORM Reactive in Ordnung ist hibernate-orm-reactive aber @FroMage, was ist mit "Panache Rx" über eine ähnliche Transformation?

@emmanuelbernard Beachten Sie, dass der aktuelle Weg, um Session und SessionFactory lautet:

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

Ich bin mit diesem Muster ziemlich zufrieden.

JDKReactiveSession

Pfui. Das sieht schrecklich aus für etwas, das wir wahrscheinlich so oft im Code sehen.

Ich stelle mir vor, dass Query auch ein reaktives Gegenstück haben würde.

Ja, es ist bereits da und heißt derzeit RxQuery . Aber es tut vorerst nichts.

Ehrlich gesagt gefällt mir immer mehr die folgende 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);

oder:

//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);

Und dann, sobald ich sicher bin, dass ich Mutiny , kann ich einfach schreiben:

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

...

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

Ich denke, die äußere Klasse lindert das Problem des versehentlichen Autoimports erheblich. (Obwohl es andere Nachteile hat.)

das sieht genial aus @gavinking

@gavinking Ich mag deinen letzten Vorschlag sehr.

Ich denke, die äußere Klasse lindert das Problem des versehentlichen Autoimports erheblich. (Obwohl es andere Nachteile hat.)

Zum Beispiel?

@DavideD Nun, ein Nachteil ist, dass

@emmanuelbernard Beachten Sie, dass der aktuelle Weg, um Session und SessionFactory lautet:

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

Ich bin mit diesem Muster ziemlich zufrieden.

JDKReactiveSession

Pfui. Das sieht schrecklich aus für etwas, das wir wahrscheinlich so oft im Code sehen.

Nach den meisten Rückmeldungen, die ich gesammelt habe, hassen die Leute CompletionStage und entscheiden sich für RxJava oder Freunde. Diese Version wäre also die Wahl des armen Mannes.

Nach den meisten Rückmeldungen, die ich gesammelt habe, hassen die Leute CompletionStage und entscheiden sich für RxJava oder Freunde. Diese Version wäre also die Wahl des armen Mannes.

Versuchen Sie sicherzustellen, dass es keine Chance hat, verwendet zu werden? :-D

Nach den meisten Rückmeldungen, die ich gesammelt habe, hassen die Leute CompletionStage und entscheiden sich für RxJava oder Freunde. Diese Version wäre also die Wahl des armen Mannes.

Klar, ich hasse es auch.

IDEs fügen normalerweise nicht automatisch statische Importe hinzu

Das ist ein ziemlich starker Punkt dagegen, dass Sie nicht Session schreiben und einen IDE-Vorschlag zum Importieren von static Mutiny.Session , also müssen Sie es immer mit dem Präfix Mutiny.Session . Und alle Dokumente müssen auch Importe enthalten, was das Kopieren/Einfügen erschwert.

Beim Namen denke ich, dass Hibernate ORM Reactive in Ordnung ist Hibernate-orm-reactive, aber @FroMage, was ist mit "Panache Rx"

Jawohl. Es war immer ein Codename.

Das ist ein ziemlich starker Punkt dagegen, dass Sie keine Session schreiben und einen IDE-Vorschlag zum Importieren erhalten können

Ich glaube nicht, dass es so stark ist: Sie können immer noch Mutiny.SessionFactory schreiben, wie wir wahrscheinlich in der Dokumentation bleiben sollten (also müssen wir keine Importe einbeziehen, obwohl wir es vielleicht immer als allgemeine Regel sollten) .

@FroMage es ist nicht so schlimm. Gehen Sie in intelliJ zu Einstellungen > Codestil

Für das, was es wert ist, sollte Mutiny meiner Meinung nach als die Standard-API angesehen werden. Der Rest könnte unter ein compat Paket fallen. Sogar die CompletionStage/Flow Version :-)

Update: Ist es angesichts der Mutiny-Dokumente überhaupt sinnvoll, in Compat zu backen? Verlassen Sie sich dafür einfach auf Mutiny und legen Sie dem Entwickler die (eher geringe) Belastung auf, die Konvertierung durchzuführen, wenn er von einem zum anderen konvertieren muss.

• 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 fügt Mutiny Trampoline hinzu, könnte ein weiteres unterstützendes Argument dafür sein, Mutiny als Standard für Reactive Hibernate zu machen.

Diese Diskussion entwickelte sich auf der Mailingliste hibernate-dev. Wir scheinen alle geneigt zu sein, mit Hibernate Reactive ... ok?

Am besten auf die Mailingliste antworten.

Erinnerung, zur Anmeldung siehe:

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

Konkret ist dies der große Thread zu diesem Thema (unter anderem):

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

Ruhezustand Reaktiv, ok?

:Champagner:

Konkret ist dies der große Thread zu diesem Thema (unter anderem):

Was für ein großer Thread, es gibt eine einzige E-Mail ;)

Persönlich mag ich HibernateRX immer noch besser - ich stimme mit Sanne zu, dass RxJava "Rx" nicht besitzt und IMO HibernateRX ein eingängiger Name ist. Hibernate Reactive scheint eher eine Beschreibung als ein Name zu sein. Nur meine 0,02 $ und ich wollte den Mailinglisten-Thread damit nicht überladen.

Persönlich mag ich HibernateRX immer noch besser - ich stimme mit Sanne zu, dass RxJava "Rx" nicht besitzt und IMO HibernateRX ein eingängiger Name ist. Hibernate Reactive scheint eher eine Beschreibung als ein Name zu sein. Nur meine 0,02 $ und ich wollte den Mailinglisten-Thread damit nicht überladen.

Das Problem @aguibert ist, wofür das x in Ihrem Hibernate Rx-Namen steht?
Reactive Extension ist etwas Bestimmtes https://en.m.wikipedia.org/wiki/Reactive_extensions

richtig, ich würde denken, Hibernate Rx würde nur für "Hibernate Reactive Extensions" stehen. Reactive Extensions ist etwas Bestimmtes, aber es bezieht sich auf ein Konzept, nicht auf ein bestimmtes Produkt oder Projekt. IMO passt das, was wir hier machen, immer noch zu diesem Konzept.

Da es so aussieht, als wären wir mit dem Namen "Hibernate Reactive" einem Konsens so nahe, wie wir ihn jemals bekommen werden, bin ich mit diesem Namen auch völlig in Ordnung.

Ich werde dies schließen, da es keine Revolte als Folge von Emmanuels E-Mail auf der Mailingliste gab :)

Hibernate Reactive es! Nochmals vielen Dank

Gefolgt von #111