当前位置: 首页 > 知识库问答 >
问题:

为什么飞行方式忽略我的 SQL 迁移文件?

邵骁
2023-03-14

我们正在我们的java,基于渐变Spring的MVC应用程序中使用飞行方式。我已将我的SQL文件保存在src/主/资源/数据库/迁移文件夹中。

下面是我的flyway gradle配置文件。

apply plugin: "org.flywaydb.flyway"

flyway {
    driver = 'com.mysql.jdbc.Driver'
    url = "jdbc:mysql://localhost:3306/java_app_test"
    user = 'root'
    password = ''
    schemas = ['java_app_test']
    outOfOrder = true
    locations = [
            //"filesystem:${project.projectDir}/dbScripts/migrations"
            "classpath:db/migration"
    ]
}

当我运行gradle flywayBaseline时,我得到如下输出。

13:57:06.291 [DEBUG] [org.flywaydb.core.internal.util.scanner.classpath.ClassPathScanner] Found resource: db/migration/20160121042238016__initial.sql
13:57:06.292 [DEBUG] [org.flywaydb.core.internal.util.scanner.classpath.ClassPathScanner] Found resource: db/migration/20160122081606826__initial.sql
13:57:06.311 [DEBUG] [org.flywaydb.core.internal.command.DbSchemas] Schema `java_app_test` already exists. Skipping schema creation.
13:57:06.358 [DEBUG] [org.flywaydb.core.internal.metadatatable.MetaDataTableImpl] MetaData table `java_app_test`.`schema_version` successfully updated to reflect changes
13:57:06.422 [INFO] [org.flywaydb.core.internal.command.DbBaseline] Schema baselined with version: 1

它找到我的sql文件,但随后它没有执行它。

当我运行flywayMigrate时,我得到以下输出

14:12:41.285 [DEBUG] [org.flywaydb.core.internal.util.scanner.classpath.ClassPathScanner] Filtering out resource: db/migration/20160121042238016__initial.sql (filename: 20160121042238016__initial.sql)
14:12:41.285 [DEBUG] [org.flywaydb.core.internal.util.scanner.classpath.ClassPathScanner] Filtering out resource: db/migration/20160122081606826__initial.sql (filename: 20160122081606826__initial.sql)
14:12:41.314 [INFO] [org.flywaydb.core.internal.command.DbValidate] Validated 1 migration (execution time 00:00.047s)
14:12:41.335 [DEBUG] [org.flywaydb.core.internal.command.DbSchemas] Schema `java_app_test` already exists. Skipping schema creation.
14:12:41.351 [DEBUG] [org.flywaydb.core.internal.dbsupport.Table] Locking table `java_app_test`.`schema_version`...
14:12:41.354 [DEBUG] [org.flywaydb.core.internal.dbsupport.Table] Lock acquired for table `java_app_test`.`schema_version`
14:12:41.358 [INFO] [org.flywaydb.core.internal.command.DbMigrate] Current version of schema `java_app_test`: 1
14:12:41.358 [WARN] [org.flywaydb.core.internal.command.DbMigrate] outOfOrder mode is active. Migration of schema `java_app_test` may not be reproducible.
14:12:41.359 [INFO] [org.flywaydb.core.internal.command.DbMigrate] Schema `java_app_test` is up to date. No migration necessary.
14:12:41.361 [DEBUG] [org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter] Finished executing task ':flywayMigrate'

这里的问题是什么?

共有3个答案

谭骏
2023-03-14

我有类似的问题,下面的文件命名惯例是“V1 _ 1 _ _我的_描述. sql”解决了这个问题

郎子平
2023-03-14

我也有类似的问题。在我的例子中,文件名在版本后面缺少了双下划线。

濮彬
2023-03-14

sqlMigrationPrefix默认为V,您的文件不以它开头。重命名您的文件或将前缀设置为空值。

 类似资料:
  • 我有一个设置,其中删除了以前脚本的迁移。飞行路线配置指定< code > ignoreMissingMigrations 为< code>true。 但是,Flyway会因以下错误而失败 验证失败:检测到应用的迁移未在本地解析:version_x 其中version_x是基线后删除的第一个版本。 为什么我会收到此错误,尽管是? 注意:Flyway版本:4.2.0

  • 我将sql迁移放在项目的rcourses文件夹中,但是我们需要创建一个基于Java的迁移,我们将其放在同一个文件夹中:http://i.stack.imgur.com/J8XEH.png 出于某种原因,基于Java的迁移被完全忽略:http://i.stack.imgur.com/9mqkk.png 我可以不将这两种类型的迁移混合在一起吗?

  • 见下图。我的.gitignore文件应该忽略src/dist中的所有文件,但事实并非如此。

  • 场景: < li >具有一个架构的现有数据库,即< code>transport架构。 < li>2个迁移文件,其中版本1是初始/基本版本。版本2向< code>management模式中添加了一个表(但没有创建该模式,我希望FlyWay来创建)。 使用FlyWay API(在Java应用程序中) 迁移版本2失败,因为尚未创建模式。这在干净的数据库上按预期成功。 我在通过maven插件执行迁移时遇

  • 我们正在使用Flyway在我们的测试环境中使用sql脚本保持最新的许多数据库,并且它工作正常。但是我们特别需要使用csv文件更新数据库。我知道Flyway提供了一些基于Java的迁移来处理更复杂的更新。但问题是,这些 Java 类的名称中都有所需的版本,这将迫使我们在每次使用该类时重新编译该类。如果我们能像对待sql文件一样将csv文件放在迁移目录中,那将更加简单。然后,一些特定的Java代码将处

  • 问题内容: 这是从CruiseControl执行时得到的: 同时,从命令行启动它可以提供正确的结果。为什么要进入这个?为什么忽略了我?我该如何解决? 我不知道从CC启动when 的值是什么。我真的很想获得这些信息,但我不知道如何。CC本身是从用户开始与该用户给我(这是CentOS的5.4): 问题答案: 假设您有一台linux机器。 看一下,这是一个符号链接。查看此符号链接的目标位置(在我的情况下