Hibernate-reactive: exportação de esquema via driver Vert.x em vez de JDBC

É um pouco estranho. Ao mesmo tempo, prefiro não ter muitas maneiras de configurar a mesma string de conexão. No futuro, um usuário provavelmente será capaz de usar ORM com Rx e pode querer usar a API Rx apenas em alguns casos. Também é bom usarmos propriedades que já são familiares para um usuário ORM.

Ah, desculpe. Acabei de perceber que você não estava falando sobre os nomes das propriedades.

Principalmente, estou me perguntando se há um caso de uso em que alguém gostaria de usar
parâmetros de configuração diferentes.
Acho que pode acontecer se o driver reativo nativo tiver algum
propriedades.

De qualquer forma, acho que teremos que ter propriedades semelhantes às do ORM, mas
com a parte jdbc removida do nome.
E decida o que acontecerá se apenas um tipo de propriedades for definido.

Na sexta-feira, 1º de maio de 2020 às 17:53 Andrew Guibert [email protected]
escreveu:

Da mesma forma, não acho que devemos ultrapassar em fazer coisas
conveniente / familiar. Por exemplo, agora oferecemos suporte para a configuração de RX com
um URL de protocolo jdbc, que é conveniente / familiar, mas não tecnicamente
correto, pois não estamos usando JDBC.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

De qualquer forma, acho que teremos que ter propriedades semelhantes às do ORM, mas com a parte jdbc removida do nome.

Acho que devemos ficar com o formato de URL JDBC padrão porque:

• é padrão
• é bem documentado pelos fornecedores de banco de dados
• todo mundo já sabe disso
• torna mais fácil configurar o Hibernate RX e o Hibernate ou JDBC simples ao mesmo tempo

@DavideD Posso não ter descrito corretamente o problema no OP, mas como os parâmetros de configuração entram em jogo para o schema gen?

Para reafirmar a intenção que tive com este problema, estou sugerindo que os procedimentos de eliminação / criação automática de tabela podem ser feitos sem a necessidade de envolver nenhum driver JDBC ou configuração somente jdbc (se RX reutilizar as mesmas propriedades , tudo bem embora)

Ah, desculpe. Acabei de perceber que você não estava falando sobre os nomes das propriedades.

Sim, entendi. Foi mal. Eu li muito rápido da primeira vez.

Parece um pouco estranho exigir que os usuários adicionem / configurem um driver JDBC se seu aplicativo estiver usando apenas RX.

Essa frase aqui me fez pensar que você estava falando sobre o fato de usarmos as propriedades para a configuração JDBC que já existe no ORM. Ainda é bom termos conversado sobre isso e não estou planejando mudá-los agora.

Portanto, anteriormente, eu estava argumentando que fazer a exportação do esquema por meio do JDBC era perfeitamente adequado. (O que é uma exportação de esquema reativo?)

No entanto, em uma conversa por telefone com @emmanuelbernard e @Sanne ,

Eu deveria ter prestado mais atenção a @aguibert quando ele tentou me avisar sobre isso.

De qualquer forma, esse é realmente um problema que devemos priorizar, embora eu suspeite que não possa ser feito a tempo para o lançamento inicial.

ideia estranha - perdoe-me se for boba, pois eu realmente não sei - mas está se perguntando se poderíamos envolver o driver reativo em um adaptador compatível com JDBC e, em seguida, alimentá-lo no código de geração de esquema?

Eu acho que esse trabalho seria um exagero se apenas facilitasse as ferramentas do schemagen, mas talvez haja mais usos?

@Sanne

Bem, há uma abstração aqui, chamada GenerationTarget . Podemos ser capazes de implementar isso, embora eu não tenha 100% de certeza de como fazer para conectar um.

Caso contrário, uma coisa que poderíamos fazer é pedir à ferramenta de exportação de esquema para exportar SCRIPT e, em seguida, apenas enviar os comandos um por um para o banco de dados.

Podemos ser capazes de implementar isso, embora eu não tenha 100% de certeza de como fazer para conectar um.

O problema é que a lista desses alvos parece estar codificada, sem nenhuma maneira óbvia de adicionar um novo. Mas uma pequena correção no núcleo pode ser o suficiente para resolver isso.

OK. Embora essa ainda não seja a prioridade principal, vou adiar o lançamento do próximo ORM tanto quanto possível, portanto, caso alguém encontre tempo, podemos incluir mais alguns patches de última hora.

Para referência, lembre-se de que realizar o lançamento realmente não leva muito tempo: cerca de 20 minutos. Mas então precisamos esperar pela sincronização central do Maven e tudo isso antes que ele possa realmente ser usado :(
O que significa que precisamos liberar cerca de 24 horas antes que uma liberação reativa seja possível.

Vou reservar algum tempo para tentar isso. Talvez seja super simples. Nós vamos descobrir.

Talvez seja super simples. Nós vamos descobrir.

Então, na verdade, era relativamente simples, mas levantou uma questão que eu não tinha considerado: Hibernate Reactive não tem mais acesso a JDBC metadata, que tem algumas conseqüências, mas eu não acho que eles são muito terrível. Felizmente, o Hibernate foi escrito quando os metadados JDBC não eram confiáveis ​​e realmente não dependem disso.

Acho que está tudo bem.

Também expôs um bug em ForeignKeys onde o Hibernate Reactive usaria realmente a conexão JDBC para obter instantâneos do banco de dados! Abrirei um relatório de bug separado para esse problema.

Incrível, obrigado!

A correção de Gavin foi incorporada ao ORM; a criação do esquema deve ser possível agora.

Suspeito que a atualização automática do esquema seja um pouco mais complicada - podemos concordar que isso é menos importante para o primeiro corte?

A correção de Gavin foi incorporada ao ORM; a criação do esquema deve ser possível agora.

Obrigado.

Eu suspeito que a atualização automática do esquema é um pouco mais complicada, embora

Ah, muito mais difícil, já que a implementação atual é inteiramente baseada em metadados JDBC, IIRC.

podemos concordar que é menos importante para o primeiro corte?

Sim, não tenho nenhuma intenção de trabalhar nisso neste momento. Nem acho que seja necessário.

@Sanne quanto tempo antes de obtermos o lançamento do núcleo ORM com essa mudança?

@gavinking podemos planejar um lançamento na segunda-feira. Mas eu me pergunto - se houver mais mudanças possivelmente necessárias, talvez seja melhor adiar?
Também estamos trabalhando em algumas outras correções de que o Quarkus precisa - então, embora possamos lançar uma sempre que quisermos, quanto mais tarde, mais correções.

@Sanne Não espere mais, esse comentário foi feito antes de eu descobrir a seriedade do # 113.

@gavinking em algum momento, você poderia escrever um problema no Vertx-sql-client descrevendo quais tipos de metadados de banco de dados são necessários para o Hibernate? O cliente Vertx deve ter uma API de metadados melhor do que tem atualmente.

1 para Andrew!

Temos a iniciativa de construir uma API de busca de metadados para Postgres em
https://github.com/eclipse-vertx/vertx-sql-client/pull/513. Feedbacks irão
certamente nos ajudará a construir uma API genérica melhor em torno disso.

Na quinta-feira, 14 de maio de 2020 às 21h58, Andrew Guibert [email protected]
escreveu:

@gavinking https://github.com/gavinking em algum momento você poderia escrever
um problema no Vertx-sql-client delineando quais tipos de metadados de banco de dados são
necessário para o Hibernate? O cliente Vertx deve ter uma API de metadados melhor
do que atualmente faz algum dia.

-
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-reactive/issues/104#issuecomment-628654875 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/ABJV4JODSAYQT7BG2TWHZI3RRP2JFANCNFSM4MXDM4CA
.

O que as ferramentas de gerenciamento de esquema precisam é de acesso às informações em information_schema.tables e também em information_schema.key_column_usage .

O que as ferramentas de gerenciamento de esquema precisam é de acesso às informações em information_schema.tables e também em information_schema.key_column_usage .

Observe que uma opção é obter essas informações diretamente consultando o information_schema . Historicamente, é apenas a API de metadados JDBC para isso, a fim de abstrair as diferenças de plataforma.

Isso está feito!

E é feito de uma maneira que é bastante transparente para o usuário: se eles tiverem um driver JDBC ou conjunto de conexões configurado, o Hibernate ORM fará a exportação de esquema por JDBC, mas se eles não tiverem um driver JDBC, então a exportação de esquema por o driver Vert.x será ativado.

Fantástico!
Muito obrigado

E é feito de uma maneira que é bastante transparente para o usuário: se eles tiverem um driver JDBC ou conjunto de conexões configurado, o Hibernate ORM fará a exportação de esquema por JDBC, mas _iff_ eles não têm um driver JDBC, então a exportação de esquema por o driver Vert.x será ativado.

só por curiosidade, por que ele deveria tentar usar a abordagem JDBC primeiro? Se temos a capacidade de executá-lo no vertx, por que não fazê-lo sempre?

Pode ficar confuso para os usuários se houver comportamentos diferentes sendo acionados apenas porque alguma conexão não relacionada está sendo configurada. Além disso - como você sabe se essa outra conexão realmente aponta para o mesmo banco de dados?

só por curiosidade, por que ele deveria tentar usar a abordagem JDBC primeiro? Se temos a capacidade de executá-lo no vertx, por que não fazê-lo sempre?

Bem, se você tem o Hibernate regular configurado ali com um driver JDBC regular, por que não usá-lo? A exportação de esquema reativo não é uma coisa significativa. Para fazer isso funcionar, temos que fazer um join() totalmente desagradável no final, o que Vert.x acha bastante perturbador.

como você sabe se aquela outra conexão realmente aponta para o mesmo banco de dados?

Porque é o mesmo URL JDBC?