Question

I make some experiments with flyway-maven-plugin. I’ve not an empty database, so I need an initial ddl script. I follow the instructions in the flyway wiki:

I put the sql script, named V1__Base_Migration.sql, in src/main/resources/db/migration.

The configuration of flyway-maven-plugin looks like the following one:

<build>
    <plugins>
        <plugin>
            <groupId>com.googlecode.flyway</groupId>
            <artifactId>flyway-maven-plugin</artifactId>
            <version>1.7</version>
            <configuration>
                <driver>org.hsqldb.jdbcDriver</driver>
                <url>jdbc:hsqldb:hsql://localhost:9001/testdb</url>
                <user>SA</user>
                <password></password>
                <schemas>PUBLIC</schemas>
                <initialVersion>1</initialVersion>
                <initialDescription>Base Migration</initialDescription>
            </configuration>
        </plugin>
    </plugins>
</build>

When I call mvn install flyway:init on the cmd and look after the run in the database, I can find the version table of flyway but not the table, whose ddl is in the sql script.

When I have a look in the debug log of Maven, I cannot find any hint that the sql script was run.

[DEBUG]   Excluded: classworlds:classworlds:jar:1.1
[DEBUG] Configuring mojo com.googlecode.flyway:flyway-maven-plugin:1.7:init from   plugin realm ClassRealm[plugin>com.googlecode.flyway:flyway-maven-plugin:1.7, parent: sun.misc.Launcher$AppClassLoader@11799e7]
[DEBUG] Configuring mojo 'com.googlecode.flyway:flyway-maven-plugin:1.7:init' with include-project-dependencies configurator -->
[DEBUG]   (f) driver = org.hsqldb.jdbcDriver
[DEBUG]   (f) initialDescription = Base Migration
[DEBUG]   (f) initialVersion = 1
[DEBUG]   (f) schemas = PUBLIC
[DEBUG]   (f) settings = org.apache.maven.execution.SettingsAdapter@1aa246e
[DEBUG]   (f) url = jdbc:hsqldb:hsql://localhost:9001/testdb
[DEBUG]   (f) user = SA
[DEBUG] -- end configuration --
[DEBUG] Database: HSQL Database Engine
[INFO] Hsql does not support locking. No concurrent migration supported.
[DEBUG] Schema: PUBLIC
[INFO] Creating Metadata table: schema_version (Schema: PUBLIC)
[DEBUG] Found statement at line 17: CREATE TABLE PUBLIC.schema_version (
version VARCHAR(20) PRIMARY KEY,
description VARCHAR(100),
type VARCHAR(10) NOT NULL,
script VARCHAR(200) NOT NULL,
checksum INT,
installed_by VARCHAR(30) NOT NULL,
installed_on TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
execution_time INT,
state VARCHAR(15) NOT NULL,
current_version BIT NOT NULL,
CONSTRAINT PUBLIC.schema_version_script_unique UNIQUE (script)
);
[DEBUG] Found statement at line 30: CREATE INDEX    PUBLIC.schema_version_current_version_index ON PUBLIC.schema_version (current_version);
[DEBUG] Executing SQL: CREATE TABLE PUBLIC.schema_version (
version VARCHAR(20) PRIMARY KEY,
description VARCHAR(100),
type VARCHAR(10) NOT NULL,
script VARCHAR(200) NOT NULL,
checksum INT,
installed_by VARCHAR(30) NOT NULL,
installed_on TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
execution_time INT,
state VARCHAR(15) NOT NULL,
current_version BIT NOT NULL,
CONSTRAINT PUBLIC.schema_version_script_unique UNIQUE (script)
)
[DEBUG] Executing SQL: CREATE INDEX PUBLIC.schema_version_current_version_index ON PUBLIC.schema_version (current_version)
[DEBUG] Metadata table created: schema_version (Schema: PUBLIC)

Do I do anyhing wrong? It would be cool, if somebody can give me a hint, what I’m doing wrong.

You can find the whole Maven test project in [github] (https://github.com/skosmalla/flyway-maven-test)

Best regards,

Sandra

Answer 1

flyway:init is useful when you have existing tables in your production schema (say ABC and XYZ) and you decide to start using Flyway to manage your DB’s lifecycle.

You can them dump the structure of the production schema in an sql script, say V0_9__Prod.sql to execute locally. This way you can align your dev DB with the current structure from PROD. As you add functionality, you can then add additional migrations like V1__Base_Migration.sql.

When deploying to PROD though, you do not want V0_9__Prod.sql to run again.
To avoid this, you can flyway:init the PROD schema with 0.9.

When it runs the migrations it will then skip V0_9__Prod.sql and move straight to V1__Base_Migration.sql.

If this situation does not apply to you, you can simply run flyway:migrate. No need for flyway:init first.