flyway - запускайте сценарии на основе SQL и Java в удаленном месте - PullRequest
0 голосов
/ 01 июня 2018

Попытка запустить файлы миграции на основе Java (скомпилированные), которых нет в проекте, где настроен Flyway.Может кто-нибудь сказать мне, возможно ли это сделать?

Я создал банку , в которой используется миграционный пролет .Jar ожидает аргумент, который определяет местоположение скриптов миграции.Скрипты миграции находятся в другом местоположении / проекте .Пока что все скрипты основаны на SQL.(т.е. XXX.sql).Нужно добавить сценарии миграции на основе Java, чтобы сделать некоторую сложную логику.

Попытался добавить pom.xml в расположение сценария и образец сценария миграции java в папке db /igration,Файл миграции на основе Java игнорируется Flyway.Это из-за контрольной суммы ошибка проверки ?

Миграции на основе Java скомпилированы и файлы .class находятся в пути к классам.Моя структура папок, как показано ниже.

C:/
└── database-migration-scripts
    └── src/main/java/
        └── db
            └── migration
                └── V1__m1.sql
                └── V2__m2.sql
                └── V3__SampleJava_script.java
    └── target/classes/
        └── db
            └── migration
                └── V3__SampleJava_script.class
    └── pom.xml

W:/
└── someLocationOutsideProject
    └── flyway-database-migration.jar

ПРИМЕЧАНИЕ: бегунок пролетного пути (баночка) и сценарии будут находиться в разных местах на одном или другом компьютере.В приведенном выше примере сценарии миграции в C:/ и jar в W:/

1 Ответ

0 голосов
/ 03 июня 2018

Чтобы быть обнаруженным , миграции Java должны идти в src/main/java с пакетом db.migration

java migration location

например,

package db.migration; // <-- classpath:db/migration

import org.flywaydb.core.api.migration.jdbc.JdbcMigration;
import java.sql.Connection;

public class V3__SampleJava_script implements JdbcMigration {
    public void migrate(Connection connection) throws Exception {
        // your code...
    }
}

Трудно диагностировать, не видя ваш pom.xml и то, как упакован ваш jar-файл, но с учетом структуры папок вашего целевого каталога выше, возможно, либо V3__SampleJava_script.class будет добавлен в jar-файл под classpath:resources/db/migration или просто не включен вообще.

Чтобы проверить, попробуйте разархивировать файл jar:

jar -xf flyway-database-migration.jar

или просто перечислить содержимое:

jar -tf flyway-database-migration.jar

ЭтоТакже стоит отметить, что если вы переопределили параметр locations с помощью пути filesystem:, в документации указано, что каталог "может содержать только миграции SQL", любые миграции Java будут просто игнорироваться.


Обновление 2018-06-03

Учитывая, что flyway-database-migration.jar указывает на местоположение filesystem:, будут обнаружены только миграции SQL, а не Java.Каталог database-migration-scripts должен быть добавлен в classpath, а местоположение пролетного пути установлено на classpath:db/migration.

java -cp C:\database-migration-scripts;<existing classpath> ...

Обновление 2018-06-09

Из-за способа, которым flyway-database-migrations.jar упакован с использованием формата Spring Boot Executable Jar , все зависимости приложения помещаются в каталог BOOT-INF/lib внутри исполняемого файла Jar и загружаются отдельным загрузчиком классов из основного класса org.springframework.boot.loader.JarLauncher.Поэтому, вопреки вышесказанному, я не уверен, что можно передать дополнительные записи пути к классам в приложение с помощью параметра командной строки -cp.Я думаю, вам нужно будет удалить загрузочную пружину и упаковать ее в обычный файл jar.Я, конечно, столкнулся с проблемами видимости класса и решил попробовать другой подход.

Я скачал Runner Command Line Runner и обновил настройки <RUNNER_DIR>/conf/flyway.conf следующим образом:

flyway.url=jdbc:mariadb://localhost:3306/flyway?createDatabaseIfNotExist=true
flyway.user=root
flyway.password=yourPassword
flyway.locations=classpath:db/migration

Я создал каталог в <RUNNER_DIR>/jars/ с именем database-migration-scripts.jar со следующей структурой (.jar важен, поскольку Flyway будет добавлять только файлы или каталоги с этим суффиксом в classpath ):

database-migration-scripts.jar/
└── db
    └── migration
        ├── V1__m1.sql
        ├── V2__m2.sql
        └── V3__SampleJava_script.class

Наконец, я добавил все зависимости времени выполнения для проекта database-migration-scripts в <RUNNER_DIR>/lib:

lib/
├── animal-sniffer-annotations-1.14.jar
├── checker-compat-qual-2.0.0.jar
├── checker-qual-2.3.0.jar
├── error_prone_annotations-2.1.3.jar
├── flyway-commandline-5.1.1.jar
├── flyway-core-5.1.1.jar
├── guava-23.6-jre.jar
├── j2objc-annotations-1.1.jar
├── jcl-over-slf4j-1.7.25.jar
├── jsr305-1.3.9.jar
├── jul-to-slf4j-1.7.25.jar
├── log4j-over-slf4j-1.7.25.jar
├── logback-classic-1.1.11.jar
├── logback-core-1.1.11.jar
├── slf4j-api-1.7.25.jar
├── snakeyaml-1.17.jar
├── spring-aop-4.3.13.RELEASE.jar
├── spring-beans-4.3.13.RELEASE.jar
├── spring-boot-1.5.9.RELEASE.jar
├── spring-boot-autoconfigure-1.5.9.RELEASE.jar
├── spring-boot-starter-1.5.9.RELEASE.jar
├── spring-boot-starter-jdbc-1.5.9.RELEASE.jar
├── spring-boot-starter-logging-1.5.9.RELEASE.jar
├── spring-context-4.3.13.RELEASE.jar
├── spring-core-4.3.13.RELEASE.jar
├── spring-expression-4.3.13.RELEASE.jar
├── spring-jdbc-4.3.13.RELEASE.jar
├── spring-tx-4.3.13.RELEASE.jar
├── tomcat-jdbc-8.5.23.jar
└── tomcat-juli-8.5.23.jar

После этого я смог успешно запустить:

./flyway migrate

И был в состоянии проверить, что миграции sql и java были успешно применены:

./flyway info

+-----------+---------+-------------------+-------------+---------------------+---------+
| Category  | Version | Description       | Type        | Installed On        | State   |
+-----------+---------+-------------------+-------------+---------------------+---------+
| Versioned | 1       | m1                | SQL         | 2018-06-09 07:41:57 | Success |
| Versioned | 2       | m2                | SQL         | 2018-06-09 07:41:57 | Success |
| Versioned | 3       | SampleJava script | SPRING_JDBC | 2018-06-09 07:47:56 | Success |
+-----------+---------+-------------------+-------------+---------------------+---------+

Фу!На мой взгляд, это гораздо сложнее, чем упаковывать миграции с приложением.

Один из других недостатков этого подхода заключается в том, что если кто-то добавляет новую миграцию Java с дополнительной зависимостью (например, commons-lang3,или что-то еще) эту зависимость также необходимо добавить в каталог <RUNNER_DIR>/lib.

Надеюсь, это поможет!

...