Estamos cambiando bases de datos, desde una que admite un 8 bits int a uno que no lo hace. Nuestro código se rompe cuando Liquibase crea una base de datos que hace que Jooq genere variables "cortas", pero nuestro código utiliza el byte / byte: estas firmas de códigos rompe.

En lugar de recodificar, alguien sugirió que continuamos usando la base de datos anterior (HSQLDB) para generar el código y "debe" ejecutar con la nueva base de datos. Hay opiniones disidentes, no puedo encontrar nada definitivo más allá de la intuición y parece ser contrario a lo que se diseñó Jooq. ¿Alguien ha hecho esto exitosamente?

1
user3481644 28 jun. 2019 a las 00:47

1 respuesta

La mejor respuesta

Obviamente, no hay respuesta absoluta sí / no a tal pregunta, pero hay varias soluciones / soluciones:

Utilice el producto de base de datos anterior para generar código.

Esto funcionará por un corto período de tiempo, por ejemplo. En este momento, pero a medida que avanza, será un factor extremadamente limitante para su diseño de esquema. Continuará con la adaptación de su DDL y algunas otras decisiones de diseño en torno a lo que HSQLDB puede hacer, y no podrá aprovechar otras características de su nuevo producto de base de datos. Esto puede ser especialmente limitante al migrar datos, ya que las declaraciones ALTER TABLE son bastante diferentes entre los dialectos.

Recomendaría este enfoque solo por un período de tiempo muy corto, por ejemplo. Si no puede arreglar esto de inmediato.

Use el mecanismo de JOOQ's <forcedType/> para reescribir sus tipos de datos

El generador de código de Jooq permite reescribir los tipos de datos antes de cargar los datos meta de su esquema en el generador de código. De esta manera, puede fingir sus tipos byte son TINYINT en su nuevo producto de base de datos, incluso si su nuevo producto de base de datos no admite TINYINT.

Esta es una solución completa que puede implementar independientemente de qué producto está usando, ya que le dará una manera de volver a definir partes de su esquema solo para el generador de código de Jooq, independientemente de cómo está generando su código .

La característica está documentada aquí: https://www.jooq.org/doc/latest/manual/code-generation/codegen-advanced/codegen-config-database/codegen-database-fordytypes

Esta es definitivamente una solución más a largo plazo para su caso.

AVISO, un futuro Jooq podrá usar las restricciones CHECK como datos de entrada de entrada para decidir si desea aplicar dicho <forcedType/>. Me imagino que colocará una restricción CHECK (my_smallint BETWEEN -128 AND 127) en cada columna, para que pueda reconocer fácilmente las columnas para aplicar el <forcedType/> a: https://github.com/jooq/jooq/issues/8843

Hasta que esté disponible esa función, puede implementarlo usted mismo a través de la configuración del generador de código programático: https://www.jooq.org/doc/latest / Manual / Generación de código / CodeGen-Programática /

O, comenzando con Jooq 3.12, utilizando una expresión de SQL para producir la expresión regular que <forcedType/> coincide. P.ej. en Oracle:

<forcedType>
  <name>TINYINT</name>
  <sql>
    select listagg(owner || '.' || table_name || '.' 
      || regexp_replace(search_condition_vc, ' between.*', ''), '|')
    from user_constraints
    where constraint_type = 'C'
    and regexp_like(search_condition_vc, '.* between -128 and 127');
  </sql>
</forcedType>

Puede utilizar una fuente de datos meta basada en archivos

Jooq no tiene que conectarse a una instancia de base de datos en vivo para invertir el ingeniero de su esquema. También puede pasar el código DDL a los archivos JoOQ o XML:

Esto no está realmente resolviendo su problema directamente, pero tal vez, podría hacerlo un poco más fácil. Sin embargo, hay otras limitaciones a estos enfoques, por ejemplo. Los procedimientos almacenados no están actualmente (Jooq 3.12) admitidos, por lo que solo estoy agregando esto para el bien de la integridad, para no sugerirle que lo use ahora mismo.

1
Lukas Eder 28 jun. 2019 a las 07:54