ForceType de restricción de comprobación o el valor por defecto

Simon Martinelli:

Tengo columnas en la base de datos que se parecen:

AKTIV VARCHAR2(1 char) default 'J' not null
    constraint AVCON_428946_AKTIV_000 check (AKTIV IN ('J', 'N')),

¿Cómo tengo que escribir el forcedType para obtener un campo booleano generado.

Hasta ahora tengo:

<forcedType>
    <userType>java.lang.Boolean</userType>
    <converter>db.Varchar2ToBooleanConverter</converter>
    <types>VARCHAR2\(1\)</types>
    <nullability>NOT_NULL</nullability>
</forcedType>

Pero, ¿cómo puedo incluir el valor predeterminado o la restricción de comprobación?

Lukas Eder:

Este es un caso de uso muy interesante, que jOOQ actualmente no puede satisfacer fuera de la caja todavía, pero usted puede rodar su propia aplicación. algunos antecedentes

¿Qué es una restricción de comprobación

Una restricción de comprobación es un predicado que se puede colocar en el esquema para validar sus datos. Si bien en muchos casos, podrá aplicar tal una restricción en una sola columna única, el hecho de que usted tiene que repetir el nombre de columna AKTIVconsejos en el hecho de que el alcance de una restricción de comprobación es realmente la mesa, no la columna. Por ejemplo, usted podría tener una restricción

CONSTRAINT chk CHECK (col1 > 0 AND col2 IN (1, 2))

Esta restricción no puede atribuirse claramente a una sola columna. Pero al igual que todas las restricciones, que puede atribuirse claramente a la mesa.

Una forma especial de la definición de restricción de comprobación en PostgreSQL y el estándar SQL son dominios , que se utilizan a menudo como restricciones de comprobación reutilizables a través de varias tablas. jOOQ actualmente no funciona con dominios. Algunas peticiones de características incluyen:

Añadir soporte para dominios de tipo
Deje que coinciden con convertidores dominios PostgreSQL en forcedType (similares a su solicitud)

Cómo hacer coincidir en jOOQ 3.11, mediante programación

jOOQ-meta ya se expone el CheckConstraintDefinitiontipo de org.jooq.meta.Database.getCheckConstraints(SchemaDefinition)Si se escribe una configuración de generador de código de programación , a continuación, puede leer las definiciones de restricción de comprobación y programación crear sus propias forcedTypeconfiguraciones en consecuencia. Esto no puede (todavía) no esté disponible en todos los dialectos SQL.

Otra alternativa sería consultar vistas del diccionario de la base de datos directamente, para encontrar las restricciones de comprobación que le parezca interesante, y luego crear forcedTypeconfiguraciones basadas en ellos. Por ejemplo, en Oracle, se podría escribir:

SELECT regexp_replace(search_condition_vc, '(\w+).*', '\1')
FROM all_constraints
WHERE constraint_name LIKE 'AVCON%' -- Add further restrictions here
AND regexp_like(search_condition_vc, 'IN\s*\(\s*''J''\s*,\s*''N''\s*\)')

Desde el proyectado SEARCH_CONDITION, ahora se puede extraer los nombres de las columnas afectadas de nuevo con una expresión regular. Obviamente, es posible que tenga que adaptar la lógica anterior a lo que sabe acerca de su dominio.

Cómo hacer coincidir en jOOQ 3.12, configurativamente

Yo sólo he implementado # 8446 en jOOQ 3.12, con el que el anterior enfoque programático también puede ser implementado configurativamente. Su <forcedType>se vería así:

<forcedType>
  <userType>java.lang.Boolean</userType>
  <converter>db.Varchar2ToBooleanConverter</converter>

  <!-- Place your SQL statement here -->
  <sql>
    SELECT regexp_replace(search_condition_vc, '(\w+).*', '\1')
    FROM all_constraints
    WHERE constraint_name LIKE 'AVCON%' -- Add further restrictions here
    AND regexp_like(search_condition_vc, 'IN\s*\(\s*''J''\s*,\s*''N''\s*\)')
  </sql>

  <!-- These may not be strictly needed -->
  <types>VARCHAR2\(1\)</types>
  <nullability>NOT_NULL</nullability>
</forcedType>