Hibernate-reactive: Reconsidere o nome "Rx"

@emmanuelbernard WDYT?

Sim, sempre foi um codinome.

Bem, então é melhor mudá-lo rápido, porque está no caminho certo para se solidificar em um nome real!

Eu atribuí isso a mim. Vou fazer isso no final da semana, a menos que alguém tenha objeções.

Vou fazer no final da semana

Mas para o que você vai mudar?

hibernate-reactive não parece tão ruim

>

+1 para hibernar reativo

Na quarta-feira, 1º de abril de 2020 às 7h45, DavideD [email protected] escreveu:

hibernate-reactive não parece tão ruim

>

-
Você está recebendo isto porque está inscrito neste tópico.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/hibernate/hibernate-rx/issues/77#issuecomment-607292426 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AADJJTIRGWQNUSN7FC3WCSLRKNHRJANCNFSM4LX6AEVQ
.

Tudo bem, mas não quero digitar ReactiveSession mil vezes ....

Eu gosto de HibernateRX : ser "reativo" é um conceito, não é uma marca registrada da RxJava.

Tudo bem, mas não quero digitar ReactiveSession mil vezes.

Modelo? Seu teclado não tem um botão de espaço? :)

Para ser justo, não gosto muito de usar um prefixo no nome de uma classe. Seria o suficiente para ter no pacote? Ou é muito confuso ao trabalhar com ORM?
Talvez pudéssemos usar R como prefixo?

Aqui está um resumo das opções que eu poderia pensar (sinta-se à vontade para sugerir algo diferente):

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

Alguma outra sugestão?

Não tenho uma preferência forte. Acho que Reactive torna o nome mais legível e não é tão longo. Observe que não é necessário um prefixo porque para alguma implementação ou classe que estende uma superclasse poderia ser algo como:

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

Isso não é muito consistente no projeto agora. Às vezes, as aulas estão usando
RxAbstractEntityPersister

Acho que vou usar a opção 3: org.hibernate.reactive.ReactiveSession
Mas vou esperar para ouvir se há sugestões melhores ou opiniões fortes contra isso.

Eu votaria em 3 também, mas talvez @vietj também tenha uma opinião?

Sim, eu estava tentando encontrar uma opção melhor, mas francamente não consegui e concordo com vocês: não parece haver nada realmente melhor do que ReactiveSession .

Eu odeio a falta de apelidos de tipo em Java. O único hack em que consigo pensar seria ter Reactive.Session , Reactive.Query , etc, como interfaces internas de algum tipo Reactive , permitindo que você use importações estáticas se desejar. Essa é uma abordagem razoável, mas nunca vi ninguém usar em Java.

Gosto das opções 2 e 4:

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

Deixe que o nome do pacote transmita que as classes são "reativas". Se tivermos que adicionar Rx / Reactive como um prefixo para todas as classes, isso fará com que as classes pareçam cidadãos de segunda classe.

A principal desvantagem que vejo em usar o mesmo nome de classe que as contrapartes não reativas seria se esperamos que os usuários usem ambas as classes na mesma classe (exigindo nomes de classe totalmente qualificados em todos os lugares em que os tipos são expressos), mas AFAIK que não deve acontecer?

Gosto das opções 2 e 4:

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

FTR também estou de acordo com isso, no entanto, eu observaria que aumenta o risco de erro durante a autoimportação.

Dado que temos quase certeza de que teremos vários tipos de sessão reativa, gostaria de propor o seguinte:

• MutinySession para motim
• StagedSession ou algo parecido por CompletionStage
• etc

WDYT?

Esta é a única API voltada para o usuário que expõe variações de tipo reativo?

Esta é a única API voltada para o usuário que expõe variações de tipo reativo?

Entre as APIs "principais", considere também os Query equivalentes.

Só para constar, eu acredito que "Rx" soa bem, e não é _dendido_ pelo projeto RxJava - como mencionei acima - então eu gostaria de manter o nome, pois os outros simplesmente não soam bem.

Na estrutura do contrato

Não gosto da sobrecarga da interface Session , como Gavin apontou, isso leva a erros de preenchimento automático e sobrecarga cognitiva para as pessoas.

Portanto, +1 para um dos seguintes padrões:

• MutinySession , RxJava2Session , JDKReactiveSession (para CompletionStage e Flow)
• SessionMutiny , SessionRxJava2 etc

Um padrão alternativo é reactiveSession.forMutiny().[...] , reactiveSession.forJDK().[...] mas muito provavelmente seria um pesadelo de dependência. reactiveSession.unwrap(MutinySession.class) não parece trazer valor.

Alguns pontos extras:

• Rx tem 3 versões não compatíveis, então seria necessário ter o número da versão no contrato
• O irmão de CompletionStage braço é Flow, por isso chamei-o de JDKReactiveSession
• RxJava tem vários tipos múltiplos e vários tipos únicos, então cada método RxJavaXSession provavelmente estará "sobrecarregado", por exemplo fetchAsSingle() etc

Imagino que Query também teria uma contraparte reativa. BTW, ocorreu-me que os parâmetros de consulta deveriam aceitar tanto o tipo direto quanto os invólucros reativos, por exemplo Uni<String>

Quanto ao nome, acho que Hibernate ORM Reactive é bom hibernate-orm-reactive mas @FroMage e sobre "Panache Rx" ele passa por uma transformação semelhante?

@emmanuelbernard observe que a forma atual de obter Session e SessionFactory é:

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

Estou bastante feliz com esse padrão.

JDKReactiveSession

ECA. Isso parece horrível para algo que provavelmente veremos com frequência no código.

Imagino que Query também teria uma contraparte reativa.

Sim, já está lá e atualmente se chama RxQuery . Mas não faz nada por enquanto.

Honestamente, estou gostando cada vez mais da seguinte opção:

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

E então, quando eu tiver certeza de que estou usando Mutiny , posso simplesmente escrever:

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

...

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

Acho que a classe externa alivia substancialmente o problema de causar um acidente na importação automática. (Embora tenha outras desvantagens.)

que parece brilhante @gavinking

@gavinking eu realmente gostei da sua última proposta.

Acho que a classe externa alivia substancialmente o problema de causar um acidente na importação automática. (Embora tenha outras desvantagens.)

Por exemplo?

@DavideD bem, uma desvantagem é que os IDEs geralmente não adicionam importações estáticas automaticamente. (Embora você possa configurá-los para fazer isso.)

@emmanuelbernard observe que a forma atual de obter Session e SessionFactory é:

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

Estou bastante feliz com esse padrão.

JDKReactiveSession

ECA. Isso parece horrível para algo que provavelmente veremos com frequência no código.

Com base na maioria dos comentários que obtive, as pessoas odeiam CompletionStage e procuram RxJava ou amigos. Portanto, essa versão seria a escolha do homem pobre.

Com base na maior parte do feedback que obtive, as pessoas odeiam o CompletionStage e optam pelo RxJava ou por amigos. Portanto, essa versão seria a escolha do homem pobre.

Você está tentando ter certeza de que não há chance de ser usado? :-D

Pela maioria dos comentários que obtive, as pessoas odeiam CompletionStage e procuram RxJava ou amigos. Portanto, essa versão seria a escolha do homem pobre.

Claro, eu também odeio.

IDE geralmente não adicionam importações estáticas automaticamente

Esse é um ponto muito forte contra isso, que você não pode escrever Session e obter uma proposta IDE para importar static Mutiny.Session , então você sempre tem que digitá-la com o prefixo Mutiny.Session . E todos os documentos terão que incluir importações também, o que torna difícil copiar / colar.

Quanto ao nome, acho que Hibernate ORM Reactive é bom hibernate-orm-reativo, mas

sim. Sempre foi um codinome.

Esse é um ponto muito forte contra isso, que você não pode escrever uma sessão e obter uma proposta IDE para importar

Não acho que seja tão forte: eles ainda podem escrever Mutiny.SessionFactory , como provavelmente deveríamos seguir na documentação (para que não tenhamos que incluir importações, embora talvez devêssemos sempre como regra geral) .

@FroMage não é tão ruim. No intelliJ, vá para Configurações> Estilo de código> Java> Importações . No Eclipse, há algo semelhante.

Pelo que vale a pena, Mutiny deve ser considerada a API padrão na minha opinião. O resto pode cair em algum pacote compat . Mesmo a versão CompletionStage/Flow :-)

Update: Dados os documentos do Mutiny, faz sentido assar no compat? Apenas conte com o Mutiny para isso e coloque a (bastante pequena) carga sobre o desenvolvedor para fazer a conversão, caso eles precisem fazer a conversão de um para o outro.

• 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á adicionando trampolins ao Mutiny, pode ser outro argumento de apoio para tornar o Mutiny padrão para o Reactive Hibernate.

Esta discussão evoluiu na lista de discussão do hibernate-dev. Todos parecemos inclinados a ir com Hibernate Reactive ... ok?

Seria melhor responder na lista de discussão.

Lembrete, para se registrar veja:

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

Especificamente, este é o grande tópico relacionado a este problema (entre outras coisas):

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

Hibernate reativo, ok?

:champanhe:

Especificamente, este é o grande tópico relacionado a este problema (entre outras coisas):

Que grande discussão, há um único e-mail;)

Pessoalmente, ainda gosto mais de HibernateRX - concordo com Sanne que RxJava não possui "Rx" e IMO HibernateRX é um nome cativante. Hibernate Reactive parece mais uma descrição do que um nome. Apenas meus $ 0,02 e eu não queria bagunçar o tópico da lista de discussão com isso.

Pessoalmente, ainda gosto mais de HibernateRX - concordo com Sanne que RxJava não possui "Rx" e IMO HibernateRX é um nome cativante. Hibernate Reactive parece mais uma descrição do que um nome. Apenas meus $ 0,02 e eu não queria bagunçar o tópico da lista de discussão com isso.

O problema @aguibert é que o que ax representa no nome do Hibernate Rx?
Extensão reativa é algo específico https://en.m.wikipedia.org/wiki/Reactive_extensions

certo, eu acho que Hibernate Rx significa apenas "Hibernate Reactive Extensions". Extensões reativas é algo específico, mas se refere a um conceito, não a um produto ou projeto específico. IMO, o que estamos fazendo aqui ainda se encaixa nesse conceito.

Já que parece que estamos o mais perto de um consenso que jamais chegaremos com o nome "Hibernate Reactive", estou totalmente bem com esse nome também.

Vou encerrar, pois não houve revolta como consequência do e-mail de Emmanuel na lista de discussão :)

Hibernate Reactive sim! Obrigado novamente @murphye e todos

Acompanhado por # 111