Hibernate-reactive: Reconsidérer le nom "Rx"

@emmanuelbernard WDYT?

Oui, c'était toujours un nom de code.

Eh bien, nous ferions mieux de le changer rapidement, car c'est en bonne voie pour se solidifier en un vrai nom !

Je me l'ai attribué. Je vais le faire à la fin de la semaine, à moins que quelqu'un ait des objections.

je vais le faire en fin de semaine

Mais en quoi allez-vous le changer ?

hibernate-reactive ne sonne pas trop mal

>

+1 pour hiberner-réactif

Le mercredi 1er avril 2020 à 7h45, DavideD [email protected] a écrit :

hibernate-reactive ne sonne pas trop mal

>

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/hibernate/hibernate-rx/issues/77#issuecomment-607292426 ,
ou se désinscrire
https://github.com/notifications/unsubscribe-auth/AADJJTIRGWQNUSN7FC3WCSLRKNHRJANCNFSM4LX6AEVQ
.

C'est bien mais je ne veux pas taper ReactiveSession mille fois....

J'aime HibernateRX : être "réactif" est un concept, ce n'est pas une marque déposée de RxJava.

C'est bien mais je ne veux pas taper ReactiveSession mille fois.

Taper? Votre clavier n'a pas de bouton espace ? :)

Pour être juste, je n'aime pas trop utiliser un préfixe dans un nom de classe. Serait-ce suffisant d'en avoir dans le paquet ? Ou est-ce trop déroutant lorsque vous travaillez avec ORM ?
Peut-être pourrions-nous utiliser R comme préfixe ?

Voici un résumé des options auxquelles je pourrais penser (n'hésitez pas à suggérer quelque chose de différent) :

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

D'autres suggestions?

Je n'ai pas de préférence marquée. Je pense que Reactive rend le nom plus lisible et ce n'est pas si long. Notez que ce n'est pas nécessairement un préfixe car pour une implémentation ou une classe étendant une super classe, cela pourrait être quelque chose comme :

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

Ce n'est pas très cohérent dans le projet en ce moment. Parfois, les classes utilisent
RxAbstractEntityPersister

Je pense que je vais utiliser l'option 3: org.hibernate.reactive.ReactiveSession
Mais j'attendrai de savoir s'il y a de meilleures suggestions ou des opinions bien arrêtées contre cela.

Je voterais aussi pour 3 , mais peut-être que @vietj a aussi une opinion ?

Oui, j'essayais de trouver une meilleure option, mais franchement, j'ai fait un blanc et je suis d'accord avec vous : il ne semble pas y avoir quelque chose de vraiment mieux que ReactiveSession .

Je déteste le manque d'alias de type en Java. Le seul hack auquel je puisse penser serait d'avoir Reactive.Session , Reactive.Query , etc, comme interfaces internes d'un type Reactive , vous permettant d'utiliser des importations statiques si vous le souhaitez. C'est une approche raisonnable, mais que je n'ai jamais vraiment vu quelqu'un d'autre utiliser en Java.

J'aime les options 2 et 4:

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

Laissez le nom du package indiquer que les classes sont "réactives". Si nous devons ajouter Rx/Reactive comme préfixe à toutes les classes, cela donne l'impression que les classes sont des citoyens de seconde classe.

Le principal inconvénient que je vois à l'utilisation du même nom de classe que les homologues non réactifs serait si nous nous attendons à ce que les utilisateurs utilisent les deux classes dans la même classe (ce qui nécessite donc des noms de classe pleinement qualifiés partout où les types sont exprimés), mais AFAIK cela ne devrait pas arriver?

J'aime les options 2 et 4:

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

FTR Je suis également d'accord avec cela, cependant, je voudrais noter que cela augmente le risque d'erreur lors de l'importation automatique.

Étant donné que nous sommes finalement presque certains d'avoir plusieurs saveurs de session réactive, je voudrais proposer ce qui suit :

• MutinySession pour Mutinerie
• StagedSession ou quelque chose comme ça pour CompletionStage
• etc

WDYT ?

Est-ce la seule API orientée utilisateur qui expose des saveurs de type réactif ?

Est-ce la seule API orientée utilisateur qui expose des saveurs de type réactif ?

Parmi les API "principales", considérez également les équivalents Query .

Pour mémoire, je pense que "Rx" sonne bien et qu'il n'appartient pas du tout au projet RxJava - comme je l'ai mentionné ci-dessus - donc j'aimerais garder le nom car les autres ne sonnent pas bien.

Sur la structure du contrat

Je n'aime pas la surcharge de l'interface Session , comme l'a souligné Gavin, cela conduit à des erreurs de complétion automatique et à une surcharge cognitive pour les gens.

Donc +1 pour l'un des modèles suivants :

• MutinySession , RxJava2Session , JDKReactiveSession (pour l'étape d'achèvement et le flux)
• SessionMutiny , SessionRxJava2 etc.

Un modèle alternatif est reactiveSession.forMutiny().[...] , reactiveSession.forJDK().[...] mais cela ferait très probablement un cauchemar de dépendance. reactiveSession.unwrap(MutinySession.class) ne semble pas apporter de valeur.

Quelques points supplémentaires :

• Rx a 3 versions non compatibles donc il faudrait avoir le numéro de version dans le contrat
• Le frère de bras de CompletionStage est Flow, c'est pourquoi je l'ai appelé JDKReactiveSession
• RxJava a plusieurs types multiples et plusieurs types simples, donc chaque méthode RxJavaXSession sera probablement "surchargée", par exemple fetchAsSingle() etc.

J'imagine que Query aurait également une contrepartie réactive. BTW, il m'est venu à l'esprit que les paramètres de requête devraient accepter à la fois le type direct et les wrappers réactifs, par exemple Uni<String>

Sur le nom, je suppose que Hibernate ORM Reactive est bien hibernate-orm-reactive mais @FroMage et "Panache Rx" passe-t-il par une transformation similaire?

@emmanuelbernard note que la façon actuelle d'obtenir un Session et un SessionFactory est :

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

Je suis assez content de ce modèle.

JDKReactiveSession

Pouah. Cela semble horrible pour quelque chose que nous sommes susceptibles de voir si souvent dans le code.

J'imagine que Query aurait également une contrepartie réactive.

Oui, il est déjà là et il s'appelle actuellement RxQuery . Mais ça ne fait rien pour l'instant.

Honnêtement, j'aime de plus en plus l'option suivante :

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

ou:

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

Et puis, une fois que je sais avec certitude que j'utilise Mutiny , je peux simplement écrire :

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

...

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

Je pense que la classe externe atténue considérablement le problème d'accident de l'importation automatique. (Bien qu'il ait d'autres inconvénients.)

ça a l'air génial @gavinking

@gavinking J'aime beaucoup ta dernière proposition.

Je pense que la classe externe atténue considérablement le problème d'accident de l'importation automatique. (Bien qu'il ait d'autres inconvénients.)

Par exemple?

@DavideD eh bien, un inconvénient est que les IDE n'ajoutent généralement pas automatiquement d'importations statiques. (Bien que vous puissiez les configurer pour le faire.)

@emmanuelbernard note que la façon actuelle d'obtenir un Session et un SessionFactory est :

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

Je suis assez content de ce modèle.

JDKReactiveSession

Pouah. Cela semble horrible pour quelque chose que nous sommes susceptibles de voir si souvent dans le code.

D'après la plupart des commentaires que j'ai recueillis, les gens détestent CompletionStage et optent pour RxJava ou des amis. Cette version serait donc le choix du pauvre.

D'après la plupart des commentaires que j'ai recueillis, les gens détestent CompletionStage et optent pour RxJava ou des amis. Cette version serait donc le choix du pauvre.

Essayez-vous de vous assurer qu'il n'a aucune chance d'être utilisé ? :-RÉ

D'après la plupart des commentaires que j'ai recueillis, les gens détestent CompletionStage et optent pour RxJava ou des amis. Cette version serait donc le choix du pauvre.

Bien sûr, je déteste ça aussi.

Les IDE n'ajoutent généralement pas automatiquement les importations statiques

C'est un point assez fort contre cela, que vous ne pouvez pas écrire Session et obtenir une proposition IDE pour importer static Mutiny.Session , vous devez donc toujours le taper avec le préfixe Mutiny.Session . Et tous les documents devront également inclure des importations, ce qui rend difficile le copier/coller.

Sur le nom, je suppose que Hibernate ORM Reactive est bien hibernate-orm-reactive mais @FroMage qu'en est-il de "Panache Rx" passe-t-il par une transformation similaire?

Oui. Ça a toujours été un nom de code.

C'est un point assez fort contre cela, que vous ne pouvez pas écrire une session et obtenir une proposition IDE à importer

Je ne pense pas que ce soit si fort : ils peuvent toujours écrire Mutiny.SessionFactory , comme nous devrions probablement nous en tenir à la documentation (nous n'aurons donc pas à inclure les importations, même si nous devrions peut-être toujours le faire en règle générale) .

@FroMage ce n'est pas si mal. Dans intelliJ, accédez à Paramètres > Style de code > Java > Importations . Dans Eclipse, il y a quelque chose de similaire.

Pour ce que ça vaut, Mutiny devrait être considéré comme l'API par défaut à mon avis. Le reste pourrait relever d' compat forfait CompletionStage/Flow :-)

Mise à jour : Compte tenu de la documentation sur Mutiny, est-il même logique de cuire en mode compatible ? Comptez simplement sur Mutiny pour cela et mettez le (assez petit) fardeau sur le développeur pour effectuer la conversion s'il a besoin de convertir de l'un à l'autre.

• 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 ajoute des trampolines à Mutiny, cela pourrait être un autre argument de soutien pour faire de Mutiny la valeur par défaut pour Reactive Hibernate.

Cette discussion a évolué sur la liste de diffusion hibernate-dev. Nous semblons tous enclins à aller avec Hibernate Reactive ... ok?

Le mieux serait de répondre sur la liste de diffusion.

Rappel, pour s'inscrire voir :

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

Plus précisément, c'est le gros fil concernant ce problème (entre autres) :

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

Hibernation réactive, d'accord ?

:Champagne:

Plus précisément, c'est le gros fil concernant ce problème (entre autres) :

Quel gros fil, il n'y a qu'un seul mail ;)

Personnellement, j'aime toujours mieux HibernateRX - je suis d'accord avec Sanne que RxJava ne possède pas "Rx" et IMO HibernateRX est un nom accrocheur. Hibernate Reactive ressemble plus à une description qu'à un nom. Juste mes 0,02 $ et je ne voulais pas encombrer le fil de la liste de diffusion avec cela.

Personnellement, j'aime toujours mieux HibernateRX - je suis d'accord avec Sanne que RxJava ne possède pas "Rx" et IMO HibernateRX est un nom accrocheur. Hibernate Reactive ressemble plus à une description qu'à un nom. Juste mes 0,02 $ et je ne voulais pas encombrer le fil de la liste de diffusion avec cela.

Le problème @aguibert est que que signifie le x dans votre nom Hibernate Rx ?
L'extension réactive est quelque chose de spécifique https://en.m.wikipedia.org/wiki/Reactive_extensions

à droite, je pense que Hibernate Rx signifierait simplement "Hibernate Reactive Extensions". Les extensions réactives sont quelque chose de spécifique, mais elles font référence à un concept, pas à un produit ou un projet particulier. OMI, ce que nous faisons ici correspond toujours à ce concept.

Puisqu'il semble que nous soyons aussi proches du consensus que nous n'aurons jamais avec le nom "Hibernate Reactive", je suis tout à fait d'accord avec ce nom aussi.

Je ferme ceci car il n'y a pas eu de révolte suite à l'email d'Emmanuel sur la liste de diffusion :)

Hibernate Reactive c'est ça ! Merci encore @murphye et à tous

Suivi par #111