# PostgreSQL
flyway.url = jdbc:postgresql://localhost:5432/postgres"external nofollow" target="_blank" href="https://flywaydb.org/documentation/commandline/">下载并安装该命令行工具。Flyway会依次搜索以下配置文件，越靠后的配置会覆盖靠前的配置：


  
/conf/flyway.conf
  
/flyway.conf
  
/flyway.conf

一个典型Flyway项目示例目录结构如下：

更多关于Flyway命令行使用可以参考Flyway Command-line。
在Gradle中的应用
首先需要在Gradle中引入Flyway插件，通常有两种方式：
方式一：采用buildscript依赖方式。


buildscript {
repositories {
mavenCentral()
}
dependencies {
classpath("org.flywaydb:flyway-gradle-plugin:4.0.3")
}
}
apply plugin: 'org.flywaydb.flyway'


方式二（推荐）：采用DSL方式引用Plugins。


plugins {
id "org.flywaydb.flyway" version "4.0.3"
}


而在Gradle中配置Flyway Properties有两种方式：
方式一：在build.gradle中配置Flyway Properties。


flyway {
url = jdbc:h2:./.tmp/testdb
user = sa
password =
}
# 或者写成：
project.ext['flyway.url'] = 'jdbc:h2:./.tmp/testdb'
project.ext['flyway.user'] = 'sa'
project.ext['flyway.password'] = ''


方式二：在gradle.properties中配置Flyway Properties。


flyway.url = jdbc:h2:./.tmp/testdb
flyway.user = sa
flyway.password =


如果期望在运行Gradle Clean/Build Tasks时自动执行Flyway的某些任务，可以设置dependsOn，若不期望隐式执行Flyway任务，可以不配置。


clean.dependsOn flywayRepair # To repair the Flyway metadata table
build.dependsOn flywayMigrate # To migrate the schema to the latest version


另外，其它Tasks：flywayInfo,flywayValidate,flywayBaseline分别对应到Flyway的命令。在使用Spring Boot时，运行./gradlew bootRun会自动检查并加载最新的db.migration脚本。
特别注意：在Production环境中不应执行./gradlew flywayClean，除非你知道自己的行为和目的，因为该命令会清除所有的数据库对象，相当危险。
更多关于Flyway在Gradle中的使用请参阅Flyway Gradle Plugin。
与Spring Boot集成
在Spring Boot中，如果加入Flyway的依赖，则会自动引用Flyway并使用默认值，但可以修改并配置FlywayProperties。


flyway.baseline-description= # The description to tag an existing schema with when executing baseline.
flyway.baseline-version=1 # Version to start migration.
flyway.baseline-on-migrate=false # Whether to execute migration against a non-empty schema with no metadata table
flyway.check-location=false # Check that migration scripts location exists.
flyway.clean-on-validation-error=false # will clean all objects. Warning! Do NOT enable in production!
flyway.enabled=true # Enable flyway.
flyway.encoding=UTF-8 # The encoding of migrations.
flyway.ignore-failed-future-migration=true # Ignore future migrations when reading the metadata table.
flyway.init-sqls= # SQL statements to execute to initialize a connection immediately after obtaining it.
flyway.locations=classpath:db/migration # locations of migrations scripts.
flyway.out-of-order=false # Allows migrations to be run "out of order".
flyway.placeholder-prefix= # The prefix of every placeholder.
flyway.placeholder-replacement=true # Whether placeholders should be replaced.
flyway.placeholder-suffix=} # The suffix of every placeholder.
flyway.placeholders.*= # Placeholders to replace in Sql migrations.
flyway.schemas= # Default schema of the connection and updating
flyway.sql-migration-prefix=V # The file name prefix for Sql migrations
flyway.sql-migration-separator=__ # The file name separator for Sql migrations
flyway.sql-migration-suffix=.sql # The file name suffix for Sql migrations
flyway.table=schema_version # The name of Flyway's metadata table.
flyway.url= # JDBC url of the database to migrate. If not set, the primary configured data source is used.
flyway.user= # Login user of the database to migrate. If not set, use spring.datasource.username value.
flyway.password= # JDBC password if you want Flyway to create its own DataSource.
flyway.validate-on-migrate=true # Validate sql migration CRC32 checksum in classpath.


若使用Gradle，通常在build.gradle引入org.flywaydb:flyway-core:4.0.3依赖后即可使用。可能会有以下几种需求：

  
在本地Run和Tests都会使用内存数据库，其中的spring.jpa.hibernate.ddl-auto都设置为validate，Schema不需要Hibernate自动生成，并期望使用Flyway，而在线上环境会使用真实数据库，并不期望使用Flyway，如何实现呢？
  
解决方案：可以在common.properties中配置flyway.enabled=false，然后在local或dev的配置中启用Flyway即可。通常推荐使用此模式，毕竟可以对不同的环境进行控制，另外本地Run不会依赖真实数据库，又能保证数据库Schema是按脚本创建的。
  
在运行Tests会使用内存数据库，有单独的配置文件，不使用Flyway，而在本地bootRun时会使用真实数据库，使用Flyway，毕竟不想每次Schema改后都在本地手动去执行脚本，如何实现？

解决方案：设置bootRun.dependsOn动态添加Flyway的依赖即可：


addFlywayDenpendency {
doLast {
dependencies {
compile('org.flywaydb:flyway-core:4.0.3')
}
}
}
bootRun.dependsOn=addFlywayDenpendency


若项目有多个团队同时开发不同的功能，需要新建多个分支，并且都会涉及到数据库Schema更改，当后期Merge时，Migration的版本如何控制并且不会产生数据库更改的冲突呢？

解决方案：如果两个分支的数据库更改有冲突，要么最初数据库设计不合理，要么目前数据库更改不合理，所以需要团队进行全局考虑和协调。而针对数据库在同一段时间有修改，但不会造成冲突的情况，通常实际项目中主要存在这样的情况，那可以设置flyway.out-of-order=true，这样允许当v1和v3已经被应用后，v2出现时同样也可以被应用。其实在本地使用内存数据库不会存在该问题，因为数据库所有对象会自动清除掉，而在local或dev中使用真实数据库时可遇到这样的问题，因此需要注意一下了。

另外，值得一提的是Flyway的参数ignore-failed-future-migration默认为true，使用情形为：当Rollback数据库更改到旧版本，而metadata表中已存在了新版本时，Flyway会忽略此错误，只会显示警告信息。
结束语
总得来说，Flyway可以有效改善数据库版本管理方式，如果项目中还未使用，不防尝试一下。如果有兴趣，也可以关注MyBatis Migration，功能支持没有Flyway多，属于更轻量级的数据库版本管理工具。如果在使用过程中遇到了问题或坑，欢迎留言一起交流讨论。
References
Flyway Documentation
Gradle Plugin: Flyway
Spring Common application properties
Execute Flyway database migrations on startup