Блог

Главная - Вопросы по программированию - Принудительный ввод при проверке ограничения или значения по умолчанию

Принудительный ввод при проверке ограничения или значения по умолчанию

#java #sql #jooq

#java #sql #jooq

Вопрос:

У меня есть столбцы в базе данных, которые выглядят как:

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

Как я должен написать forcedType, чтобы сгенерировать логическое поле.

Пока у меня есть:

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

Но как мне включить значение по умолчанию или ограничение проверки?

Ответ №1:

Это очень интересный вариант использования, который jOOQ в настоящее время не может удовлетворить из коробки, но вы можете создать свою собственную реализацию. Некоторая предыстория

Что такое ограничение проверки

Ограничение проверки — это предикат, который может быть помещен в схему для проверки ваших данных. Хотя во многих случаях вы применяете такое ограничение только к одному столбцу, тот факт, что вам приходится повторять имя столбца AKTIV , намекает на тот факт, что область действия ограничения проверки на самом деле является таблицей, а не столбцом. Например, у вас может быть ограничение

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

Это ограничение не может быть четко отнесено к одному столбцу. Но, как и все ограничения, это может быть явно отнесено к таблице.

Особым способом определения ограничения проверки в PostgreSQL и стандарте SQL являются домены, которые часто используются в качестве многоразовых ограничений проверки в нескольких таблицах. jOOQ в настоящее время не работает с доменами. Некоторые запросы функций включают:

Как сопоставить их в jOOQ 3.11 программно

jOOQ-meta уже предоставляет CheckConstraintDefinition тип из org.jooq.meta.Database.getCheckConstraints(SchemaDefinition) , если вы пишете конфигурацию генератора программного кода, тогда вы можете прочитать определения проверки ограничения и программно создать свои собственные forcedType конфигурации соответствующим образом. Это может быть (пока) доступно не во всех диалектах SQL.

Другой альтернативой было бы запросить представления словаря вашей базы данных напрямую, чтобы найти ограничения проверки, которые вам кажутся интересными, а затем создать forcedType конфигурации на их основе. Например, в Oracle вы могли бы написать:

 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, 'INs*(s*''J''s*,s*''N''s*)')

Из спроектированного SEARCH_CONDITION теперь вы можете снова извлечь затронутые имена столбцов с помощью регулярного выражения. Очевидно, вам может потребоваться адаптировать приведенную выше логику к тому, что вы знаете о своем домене.

Как сопоставить их в jOOQ 3.12, конфигурационно

Я только что реализовал # 8446 в jOOQ 3.12, с помощью которого вышеупомянутый программный подход также может быть реализован конфигурационно. Ваш <forcedType> будет выглядеть следующим образом:

 <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, 'INs*(s*''J''s*,s*''N''s*)')
  </sql>

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