Java jOOQ使用一个数据库生成代码，另一个数据库执行代码

我们正在改变数据库，从一个支持8位int的数据库到一个不支持8位int的数据库。当Liquibase创建一个DB导致jOOQ生成“短”变量时，我们的代码会中断，但我们的代码使用字节/字节-这会中断代码签名

---

有人建议我们继续使用以前的数据库（HSQLDB）来生成代码，而不是重新编码，它“应该”与新数据库一起运行。有不同的意见，除了直觉，我找不到任何决定性的东西，这似乎与jOOQ的设计目的背道而驰。有人成功地做到了这一点吗？

对于这样的问题，显然没有绝对的是/否答案，但有几种解决方案/变通方法：

使用以前的数据库产品生成代码 这将在短时间内起作用，例如现在，但随着您的继续，它将成为模式设计的一个极其有限的因素。您将继续围绕HSQLDB的功能定制DDL和其他一些设计决策，而您将无法利用新数据库产品的其他功能。在迁移数据时，这可能特别有限，因为不同方言的

altertable

语句非常不同

我建议这种方法只在很短的时间内使用，例如，如果您不能立即彻底解决此问题

使用jOOQ的

机制重写数据类型 jOOQ的代码生成器允许在将模式的元数据加载到代码生成器之前重写数据类型。这样，即使新数据库产品不支持

TINYINT

，您也可以在新数据库产品上假装您的

byte

类型是

TINYINT

这是一个彻底的解决方案，无论您使用的是什么产品，您都可能希望实现它，因为它将为您提供一种方法，仅为jOOQ的代码生成器重新定义部分模式，而与您如何生成代码无关

此处记录了该功能：

对于您的案例，这无疑是一个更长期的解决方案

注意，未来的jOOQ将能够使用

检查
约束作为输入元数据来决定是否应用这样的
。我可以想象，您将在每个这样的列上放置一个
检查（my_smallint介于-128和127之间）
约束，这样您就可以很容易地识别将
应用于哪些列：

在该功能可用之前，您可以通过编程代码生成器配置自行实现该功能：

或者，从jOOQ 3.12开始，使用SQL表达式生成匹配的正则表达式。例如，在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>


锡
选择listagg（所有者| |'。| |表格| |'。'
||regexp_replace（搜索条件_vc，'between.*'，''，'124;'）
从用户约束
其中约束类型='C'
和regexp_like（search_condition_vc，'.*介于-128和127'之间）；

您可以使用基于文件的元数据源
jOOQ无需连接到实时数据库实例即可对模式进行反向工程。您还可以将DDL代码传递给jOOQ或XML文件：





这并不是直接解决你的问题，但也许，这会让解决问题变得更容易一些。但是，这些方法还有其他限制，例如，存储过程目前（jOOQ 3.12）不受支持，所以我只是为了完整起见在这里添加它，而不是建议您现在就使用它。
我花了一段时间才回到这里，我们确实使用了forcedType方法，还遇到了其他问题，例如使用的能力“max（boolean）”在一个引擎中，因为boolean实际上是整数，但在另一个引擎中失败了（这是应该的）。使用“max（boolean）”实际上是一个带有分组的“are any set？”。@user3481644:您可以改为使用