Hibernate-reactive: exportación de esquema a través del controlador Vert.x en lugar de JDBC

Es un poco raro. Al mismo tiempo, preferiría no tener demasiadas formas de configurar la misma cadena de conexión. En el futuro, un usuario probablemente podrá usar ORM con Rx y es posible que desee usar la API de Rx solo en algunos casos. También es bueno que usemos propiedades que ya son familiares para un usuario de ORM.

Oh, lo siento. Me acabo de dar cuenta de que no hablaba de los nombres de las propiedades.

Sobre todo, me pregunto si hay un caso de uso en el que uno quisiera usar
diferentes parámetros de configuración.
Supongo que podría suceder si el controlador reactivo nativo tiene algún
propiedades.

De todos modos, supongo que tendremos que tener propiedades similares a las de ORM pero
con la parte jdbc eliminada del nombre.
Y decida qué sucede si solo se establece un tipo de propiedades.

El viernes 1 de mayo de 2020 a las 5:53 p.m. Andrew Guibert [email protected]
escribió:

De la misma manera, no creo que debamos excedernos en hacer cosas
conveniente / familiar. Por ejemplo, ahora admitimos la configuración de RX con
una URL de protocolo jdbc, que es conveniente / familiar pero no técnicamente
correcto ya que no estamos usando JDBC.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/hibernate/hibernate-rx/issues/104#issuecomment-622468348 ,
o darse de baja
https://github.com/notifications/unsubscribe-auth/AAEIQ5JHS5PQ7M7APGO2YVLRPL5APANCNFSM4MXDM4CA
.

De todos modos, supongo que tendremos que tener propiedades similares a las de ORM pero con la parte jdbc eliminada del nombre.

Creo que deberíamos seguir con el formato de URL estándar de JDBC porque:

• es estándar
• está bien documentado por los proveedores de bases de datos
• todo el mundo ya lo sabe
• facilita la configuración de Hibernate RX y Hibernate simple o JDBC simple al mismo tiempo

@DavideD Es posible que no haya descrito correctamente el problema en el OP, pero ¿cómo entran en juego los parámetros de configuración para la generación de esquemas?

Para reafirmar la intención que tuve con este problema, sugiero que los procedimientos automáticos de eliminación / creación de tablas se pueden realizar sin necesidad de involucrar ningún controlador JDBC o configuración solo de jdbc (si RX reutiliza las mismas propiedades , eso está bien aunque)

Oh, lo siento. Me acabo de dar cuenta de que no hablaba de los nombres de las propiedades.

Sí, lo tengo. Mi error. Lo leí demasiado rápido la primera vez.

Parece un poco incómodo exigir a los usuarios que agreguen / configuren un controlador JDBC si su aplicación solo usa RX.

Esta oración aquí me hizo pensar que estaba hablando del hecho de que usamos las propiedades para la configuración JDBC que ya existen en ORM. Todavía es bueno que hayamos hablado de eso y no planeo cambiarlos por ahora.

Así que anteriormente estaba argumentando que hacer la exportación del esquema a través de JDBC estaba perfectamente bien. (¿Qué es una exportación de esquema reactivo?)

Sin embargo, en una conversación telefónica con @emmanuelbernard y @Sanne , me he dado cuenta de que este es en realidad un punto de dolor potencial para los usuarios de Quarkus.

Debería haberle prestado más atención a @aguibert cuando intentó advertirme sobre esto.

Entonces, de todos modos, este es un tema que debemos priorizar, aunque sospecho que no se puede hacer a tiempo para el lanzamiento inicial.

idea extraña, perdóneme si es una tontería, ya que realmente no lo sé, pero me pregunto si podríamos envolver el controlador reactivo en un adaptador compatible con JDBC y luego introducirlo en el código de generación del esquema.

Supongo que ese trabajo sería excesivo si solo facilitara las herramientas de Schemagen, pero ¿quizás hay más usos?

@Sanne

Bueno, aquí hay una abstracción, llamada GenerationTarget . Es posible que podamos implementar eso, aunque no estoy 100% seguro exactamente de cómo se conecta uno.

De lo contrario, una cosa que podríamos hacer es pedirle a la herramienta de exportación de esquemas que exporte un SCRIPT , y luego simplemente envíe los comandos uno por uno a la base de datos.

Es posible que podamos implementar eso, aunque no estoy 100% seguro exactamente de cómo se conecta uno.

El problema es que la lista de estos objetivos parece estar codificada, sin ninguna forma obvia de agregar uno nuevo. Pero una pequeña corrección en el núcleo podría ser suficiente para resolver eso.

Está bien. Si bien esta todavía no es la máxima prioridad, aplazaré el lanzamiento del próximo ORM tanto como sea posible, por lo que en caso de que alguien encuentre el tiempo, podemos incluir algunos parches más de última hora.

Como referencia, recuerde que realizar el lanzamiento realmente no nos lleva mucho tiempo: unos 20 minutos. Pero luego tenemos que esperar la sincronización central de Maven y todo eso antes de que realmente se pueda usar :(
Lo que implica que tenemos que lanzar alrededor de 24 horas antes de que sea posible un lanzamiento reactivo.

Dedicaré algo de tiempo para intentar esto. Quizás sea súper simple. Lo averiguaremos.

Quizás sea súper simple. Lo averiguaremos.

Entonces, de hecho, fue relativamente sencillo, pero planteó un problema que no había considerado: Hibernate Reactive ya no tiene acceso a los metadatos de JDBC, lo que tiene algunas consecuencias, pero no creo que sean demasiado terribles. Afortunadamente, Hibernate se escribió cuando los metadatos de JDBC eran muy poco fiables y no dependen realmente de ellos.

Supongo que está bien.

¡También expuso un error en ForeignKeys donde Hibernate Reactive realmente usaría la conexión JDBC para obtener instantáneas de la base de datos! Abriré un informe de error por separado para ese problema.

¡Genial gracias!

La solución de Gavin se fusionó en ORM; La creación de esquemas debería ser factible ahora.

Sin embargo, sospecho que la actualización automática del esquema es un poco más complicada, ¿podemos estar de acuerdo en que es menos importante para el primer corte?

La solución de Gavin se fusionó en ORM; La creación de esquemas debería ser factible ahora.

Gracias.

Sin embargo, sospecho que la actualización automática del esquema es un poco más complicada

Oh, mucho más difícil, ya que la implementación actual se basa completamente en metadatos JDBC, IIRC.

¿Podemos estar de acuerdo en que eso es menos importante para el primer corte?

Sí, no tengo ninguna intención de trabajar en eso en esta etapa. Tampoco creo que sea necesario.

@Sanne ¿cuánto tiempo antes de que obtengamos un lanzamiento del núcleo ORM con ese cambio?

@gavinking podemos planear un lanzamiento el lunes. Sin embargo, me pregunto: si es posible que se necesiten más cambios, ¿quizás sea mejor posponerlo?
También estamos trabajando en algunas otras correcciones que Quarkus necesita, por lo que, si bien podemos lanzar una cuando queramos, cuanto más tarde, más correcciones.

@Sanne No, agárrate fuerte, ese comentario fue hecho antes de que descubriera la seriedad del # 113.

@gavinking en algún momento, ¿podría escribir un problema en Vertx-sql-client que describa qué tipo de metadatos de base de datos necesita Hibernate? El cliente Vertx debería tener una API de metadatos mejor de la que tiene actualmente algún día.

¡+1 para Andrew!

Tenemos una iniciativa para construir una API de obtención de metadatos para Postgres en
https://github.com/eclipse-vertx/vertx-sql-client/pull/513. Las retroalimentaciones
ciertamente nos ayudará a construir una mejor API genérica en torno a esto.

El jueves 14 de mayo de 2020 a las 9:58 p.m. Andrew Guibert [email protected]
escribió:

@gavinking https://github.com/gavinking en algún momento podrías escribir
hasta un problema en Vertx-sql-client que describe qué tipo de metadatos de base de datos es
que necesita Hibernate? El cliente Vertx debería tener una mejor API de metadatos
de lo que lo hace actualmente algún día.

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

Lo que necesitan las herramientas de administración de esquemas es acceso a la información en information_schema.tables y supongo que también information_schema.key_column_usage .

Lo que necesitan las herramientas de administración de esquemas es acceso a la información en information_schema.tables y supongo que también information_schema.key_column_usage .

Tenga en cuenta que una opción es obtener esa información directamente consultando el information_schema . Históricamente, solo era la API de metadatos de JDBC para eso, con el fin de abstraerse de las diferencias de plataforma.

¡Esto esta hecho!

Y se hace de una manera que es bastante transparente para el usuario: si tienen un controlador JDBC o un grupo de conexiones configurado, Hibernate ORM exportará el esquema a través de JDBC, pero si no tiene un controlador JDBC, entonces exportará el esquema. el controlador Vert.x se activará.

¡Eso es genial!
Muchas gracias

Y se hace de una manera que es bastante transparente para el usuario: si tienen un controlador JDBC o un grupo de conexiones configurado, entonces Hibernate ORM exportará el esquema a través de JDBC pero _iff_ no tienen un controlador JDBC, luego exportará el esquema a través de el controlador Vert.x se activará.

solo por curiosidad, ¿por qué debería intentar usar el enfoque JDBC primero? Si tenemos la capacidad de ejecutarlo sobre vertx, ¿por qué no hacerlo siempre?

Puede resultar confuso para los usuarios si se activan diferentes comportamientos solo porque se está configurando alguna conexión no relacionada. Además, ¿cómo saber si esa otra conexión realmente apunta a la misma base de datos?

solo por curiosidad, ¿por qué debería intentar usar el enfoque JDBC primero? Si tenemos la capacidad de ejecutarlo sobre vertx, ¿por qué no hacerlo siempre?

Bueno, si tiene Hibernate regular allí configurado con un controlador JDBC normal, ¿por qué no usarlo? La exportación de esquemas reactivos no es algo significativo. Para que esto funcione, tenemos que hacer un join() totalmente desagradable al final, que Vert.x encuentra bastante molesto.

¿Cómo sabe si esa otra conexión realmente apunta a la misma base de datos?

¿Porque es la misma URL de JDBC?