Hibernate-reactive: Reconsidere el nombre "Rx"

@emmanuelbernard WDYT?

Sí, siempre fue un nombre en clave.

Bueno, entonces será mejor que lo cambiemos rápido, ¡porque está en el camino de solidificarse en un nombre real!

Me lo he asignado. Lo haré al final de la semana, a menos que alguien tenga objeciones.

Lo voy a hacer al final de la semana

Pero, ¿a qué lo vas a cambiar?

hibernate-reactive no suena tan mal

>

+1 para hibernar-reactivo

El miércoles 1 de abril de 2020 a las 7:45 a.m., DavideD [email protected] escribió:

hibernate-reactive no suena tan mal

>

-
Estás recibiendo esto porque estás suscrito a este hilo.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/hibernate/hibernate-rx/issues/77#issuecomment-607292426 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AADJJTIRGWQNUSN7FC3WCSLRKNHRJANCNFSM4LX6AEVQ
.

Está bien, pero no quiero escribir ReactiveSession mil veces ...

Me gusta HibernateRX : ser "reactivo" es un concepto, no es una marca registrada de RxJava.

Está bien, pero no quiero escribir ReactiveSession mil veces.

¿Escribe? ¿Tu teclado no tiene un botón de espacio? :)

Para ser justos, no me gusta tanto usar un prefijo en el nombre de una clase. ¿Sería suficiente tenerlo en el paquete? ¿O es demasiado confuso cuando se trabaja con ORM?
¿Quizás podríamos usar R como prefijo?

Aquí hay un resumen de las opciones que se me ocurren (siéntase libre de sugerir algo diferente):

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

¿Cualquier otra sugerencia?

No tengo una preferencia fuerte. Creo que Reactive hace que el nombre sea más legible y no es tan largo. Tenga en cuenta que no es necesario un prefijo porque para alguna implementación o clase que extiende una superclase podría ser algo como:

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

Esto no es muy consistente en el proyecto en este momento. A veces las clases usan
RxAbstractEntityPersister

Creo que usaré la opción 3: org.hibernate.reactive.ReactiveSession
Pero esperaré a escuchar si hay mejores sugerencias u opiniones firmes en contra.

Yo también votaría por 3 , pero ¿quizás @vietj también tiene una opinión?

Sí, estaba tratando de encontrar una mejor opción, pero, francamente, me quedé en blanco y estoy de acuerdo con ustedes: no parece haber nada realmente mejor que ReactiveSession .

Odio la falta de alias de tipo en Java. El único truco en el que puedo pensar sería tener Reactive.Session , Reactive.Query , etc., como interfaces internas de algún tipo Reactive , permitiéndote usar importaciones estáticas si lo deseas. Ese es un enfoque razonable, pero nunca he visto a nadie usar en Java.

Me gustan las opciones 2 y 4:

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

Deje que el nombre del paquete transmita que las clases son "reactivas". Si tenemos que agregar Rx / Reactive como prefijo a todas las clases, hace que las clases parezcan ciudadanos de segunda clase.

La principal desventaja que veo de usar el mismo nombre de clase que las contrapartes no reactivas sería si esperamos que los usuarios usen ambas clases en la misma clase (por lo tanto, se requieren nombres de clase completamente calificados en todos los lugares donde se expresan los tipos), pero AFAIK eso no debería ¿ocurrir?

Me gustan las opciones 2 y 4:

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

FTR También estoy de acuerdo con eso, sin embargo, me gustaría señalar que aumenta el riesgo de error al autoimportar.

Dado que, en última instancia, es casi seguro que tendremos varios tipos de sesiones reactivas, me gustaría proponer lo siguiente:

• MutinySession por Motín
• StagedSession o algo así por CompletionStage
• etc

WDYT?

¿Es esta la única API de cara al usuario que expone sabores de tipo reactivo?

¿Es esta la única API de cara al usuario que expone sabores de tipo reactivo?

Entre las API "principales", considere también los Query .

Para que conste, creo que "Rx" suena bien, y no es _propiedad_ del proyecto RxJava en absoluto, como mencioné anteriormente, así que me gustaría mantener el nombre ya que los demás simplemente no suenan bien.

Sobre la estructura del contrato

No me gusta la sobrecarga de la interfaz Session , como señaló Gavin, conduce a errores de finalización automática y una sobrecarga cognitiva para las personas.

Entonces +1 para cualquiera de los siguientes patrones:

• MutinySession , RxJava2Session , JDKReactiveSession (para etapa de finalización y flujo)
• SessionMutiny , SessionRxJava2 etc.

Un patrón alternativo es reactiveSession.forMutiny().[...] , reactiveSession.forJDK().[...] pero lo más probable es que se convierta en una pesadilla de dependencia. reactiveSession.unwrap(MutinySession.class) no parece aportar valor.

Algunos puntos extra:

• Rx tiene 3 versiones no compatibles, por lo que es necesario tener el número de versión en el contrato.
• El hermano de brazo de CompletionStage es Flow, por eso lo llamé JDKReactiveSession
• RxJava tiene varios tipos múltiples y varios únicos, por lo que es probable que cada método RxJavaXSession esté "sobrecargado", por ejemplo, fetchAsSingle() etc.

Me imagino que Query también tendría una contraparte reactiva. Por cierto, se me ocurrió que los parámetros de consulta deberían aceptar tanto el tipo directo como los contenedores reactivos, por ejemplo, Uni<String>

En el nombre, supongo que Hibernate ORM Reactive está bien hibernate-orm-reactive pero @FroMage, ¿qué pasa con "Panache Rx" Tiene una transformación similar?

@emmanuelbernard tenga en cuenta que la forma actual de obtener Session y SessionFactory es:

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

Estoy bastante contento con este patrón.

JDKReactiveSession

Puaj. Eso se ve horrible para algo que probablemente veamos con tanta frecuencia en el código.

Me imagino que Query también tendría una contraparte reactiva.

Sí, ya está allí y actualmente se llama RxQuery . Pero no hace nada por ahora.

Honestamente, cada vez me gusta más la siguiente opción:

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

o:

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

Y luego, una vez que esté seguro de que estoy usando Mutiny , puedo escribir:

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

...

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

Creo que la clase exterior alivia sustancialmente el problema de la importación automática de accidentes. (Aunque tiene otras desventajas).

eso se ve brillante @gavinking

@gavinking Me gusta mucho tu última propuesta.

Creo que la clase exterior alivia sustancialmente el problema de que la importación automática no se produzca. (Aunque tiene otras desventajas).

¿Por ejemplo?

@DavideD bueno, una desventaja es que los IDE no suelen agregar automáticamente importaciones estáticas. (Aunque puede configurarlos para que lo hagan).

@emmanuelbernard tenga en cuenta que la forma actual de obtener Session y SessionFactory es:

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

Estoy bastante contento con este patrón.

JDKReactiveSession

Puaj. Eso se ve horrible para algo que probablemente veamos con tanta frecuencia en el código.

Según la mayoría de los comentarios que he recopilado, la gente odia CompletionStage y opta por RxJava o amigos. Entonces esa versión sería la elección del pobre.

Según la mayoría de los comentarios que he recopilado, la gente odia CompletionStage y elige RxJava o amigos. Entonces esa versión sería la elección del pobre.

¿Está tratando de asegurarse de que no tenga posibilidades de ser utilizado? :-D

Según la mayoría de los comentarios que he recopilado, la gente odia CompletionStage y opta por RxJava o amigos. Entonces esa versión sería la elección del pobre.

Claro, yo también lo odio.

Los IDE no suelen agregar automáticamente importaciones estáticas

Ese es un punto bastante fuerte en su contra, que no puede escribir Session y obtener una propuesta IDE para importar static Mutiny.Session , por lo que siempre debe escribirlo con el prefijo Mutiny.Session . Y todos los documentos también tendrán que incluir importaciones, lo que dificulta copiar / pegar.

En el nombre, supongo que Hibernate ORM Reactive está bien hibernate-orm-reactivo, pero @FroMage, ¿qué pasa con "Panache Rx", tiene una transformación similar?

Si. Siempre ha sido un nombre en clave.

Ese es un punto bastante fuerte en su contra, que no puede escribir Session y obtener una propuesta de IDE para importar

No creo que sea tan fuerte: todavía pueden escribir Mutiny.SessionFactory , como probablemente deberíamos seguir en la documentación (para que no tengamos que incluir importaciones, aunque tal vez siempre deberíamos hacerlo como regla general) .

@FroMage no es tan malo. En intelliJ, vaya a Configuración> Estilo de código> Java> Importaciones . En Eclipse hay algo parecido.

Por lo que vale, Mutiny debería considerarse la API predeterminada en mi opinión. El resto podría caer en algún paquete compat . Incluso la versión CompletionStage/Flow :-)

Actualización: Dados los documentos de Mutiny, ¿tiene sentido hornear en compatibilidad? Solo confíe en Mutiny para eso, y ponga la carga (bastante pequeña) en el desarrollador para hacer la conversión si necesita convertir de uno a otro.

• 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 está agregando trampolines a Mutiny, podría ser otro argumento de apoyo para hacer que Mutiny sea predeterminado para Reactive Hibernate.

Esta discusión evolucionó en la lista de correo hibernate-dev. Todos parecemos inclinados a ir con Hibernate Reactive ... ¿de acuerdo?

Sería mejor responder en la lista de correo.

Recordatorio, para registrarse ver:

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

Específicamente, este es el gran hilo relacionado con este problema (entre otras cosas):

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

Hibernar reactivo, ¿de acuerdo?

:champán:

Específicamente, este es el gran hilo relacionado con este problema (entre otras cosas):

Qué hilo tan grande, hay un solo correo electrónico;)

Personalmente, todavía me gusta más HibernateRX. Estoy de acuerdo con Sanne en que RxJava no posee "Rx" y, en mi opinión, HibernateRX es un nombre pegadizo. Hibernate Reactive parece más una descripción que un nombre. Solo mis $ 0.02 y no quería saturar el hilo de la lista de correo con esto.

Personalmente, todavía me gusta más HibernateRX. Estoy de acuerdo con Sanne en que RxJava no posee "Rx" y, en mi opinión, HibernateRX es un nombre pegadizo. Hibernate Reactive parece más una descripción que un nombre. Solo mis $ 0.02 y no quería saturar el hilo de la lista de correo con esto.

El problema @aguibert es que ¿qué significa la x en su nombre de Hibernate Rx?
La extensión reactiva es algo específico https://en.m.wikipedia.org/wiki/Reactive_extensions

Bien, creo que Hibernate Rx simplemente significa "Hibernate Reactive Extensions". Reactive Extensions es algo específico, pero se refiere a un concepto, no a un producto o proyecto en particular. En mi opinión, lo que estamos haciendo aquí todavía se ajusta a ese concepto.

Dado que parece que estamos lo más cerca posible del consenso con el nombre "Hibernate Reactive", también estoy totalmente de acuerdo con ese nombre.

Cerraré esto ya que no hubo revuelta como consecuencia del correo electrónico de Emmanuel en la lista de correo :)

Hibernate Reactive lo es! Gracias de nuevo @murphye y todo

Seguido por # 111