如何将jOOQ自动生成器配置为基于清算模式xml文件运行？

Question

我希望jOOQ自动代码生成器在位于资源文件夹(而不是基于数据库连接)的清算模式xml文件的基础上运行。在pom.xml中，配置部分如下所示：

<configuration xmlns="http://www.jooq.org/xsd/jooq-codegen-3.13.4.xsd">
    <generator>
        <database>
            <name>org.jooq.meta.extensions.liquibase.LiquibaseDatabase</name>
            <includes>.*</includes>
            <excludes></excludes>
            <inputSchema>public</inputSchema>

            <properties>
                <property>
                    <key>scripts</key>
                    <value>/liquibase-outputChangeLog.xml</value>
                </property>

                <property>
                    <key>includeLiquibaseTables</key>
                    <value>true</value>
                </property>

                <property>
                    <key>database.liquibaseSchemaName</key>
                    <value>public</value>
                </property>
            </properties>
        </database>

        <target>
            <packageName>jooqGenerated</packageName>
            <directory>target/generated-sources/jooq</directory>
        </target>
    </generator>
</configuration>

它无法在指定的文件夹中生成jOOQ代码。

[ERROR] azure/postgresql/TrackerAzureImpl.java: package ...tables does not exist (for all the tables, I cannot even see elsewhere where jooq code is getting generated),
Also one warning: No schemata were loaded: [WARNING] No schemata were loaded  : Please check your connection settings, and whether your database (and your database version!) is really supported by jOOQ. Also, check the case-sensitivity in your configured <inputSchema/> elements : {=[public]}

请指点。

Answer 1

这很可能是因为一个bug：https://github.com/jOOQ/jOOQ/issues/12997

解释和解决办法

在幕后，在jOOQ 3.16中，LiquibaseDatabase、DDLDatabase和JPADatabase都使用内存中的H2数据库模拟数据库迁移。这在将来可能会改变，但现在是这样的。在H2中，默认情况下，所有标识符都是大写的，<inputSchema/>配置也是如此。这意味着您应该包括PUBLIC模式，而不是public模式。

注意，代码生成输出还将包含对PUBLIC的引用，而不是public，因此如果您想继续使用LiquibaseDatabase，则必须在运行时使用设置关闭对标识符的引用。

在H2上不模拟Liquibase的更健壮的替代方案

或者，您不必使用LiquibaseDatabase，正如我在其他地方提到的那样。您还可以使用测试容器直接在PostgreSQL上运行实际迁移，并反向工程一个实际的PostgreSQL数据库，而不是如本博客文章所述。