当数据库发送变更时,借助flyway,能在部署时自动执行sql,省去手动执行sql的步骤。
<dependency>
<groupId>org.flywaydb</groupId>
<artifactId>flyway-core</artifactId>
</dependency>
classpath:db/migration
,所以我们在src/main/resources
下创建对应的文件夹flyway的sql文件分成两类:Versioned和Repeatable
Versioned 一般常用的是Versioned类型,用于版本升级,每一个版本都有一个唯一的标识并且只能被应用一次,并且不能再修改已经加载过的Migrations,因为Metadata表会记录其Checksum值。其中的version标识版本号,由一个或多个数字构成,数字之间的分隔符可以采用点或下划线,在运行时下划线其实也是被替换成点了,每一部分的前导零会被自动忽略。
Repeatable Repeatable是指可重复加载的SQL,其每一次的修改会影响Checksum值,然后都会被重新加载,并不用于版本升级。对于管理不稳定的数据库对象的更新时非常有用。Repeatable的SQL总是在Versioned之后按顺序执行,但开发者必须自己维护脚本并且确保可以重复执行,通常会在sql语句中使用CREATE OR REPLACE来保证可重复执行。
其中的文件名由以下部分组成,除了使用默认配置外,某些部分还可自定义规则。
spring:
flyway:
baseline-on-migrate: true
baseline-version: 2
baseline-on-migrate
为true时,项目启动时,flyway会检测数据库是否已经存在表flyway_schema_history
,表不存在时flyway会自动创建。
baseline-version
表示基线是从哪个版本开始的,默认从1开始(如果数据库不存在flyway_schema_history
的情况下,我们需要将数据库脚本版本号命名需要从2开始,否则不会执行,因为1的版本就是初始化flyway_schema_history
)。
比如我们是中途加入flyway的,数据库已经存在表和数据了,这时我们导出一份脚本V2__init.sql
,但实际上我们不需要再执行这份脚本,这时可以把baseline-version
设置为2,这个版本的文件将跳过,可以根据不同的环境设置不同的值。
flyway是通过flyway_schema_history
表来进行比对,看哪些sql文件需要执行,执行按照版本号的顺序进行,执行过之后就有一条对应的记录。
V开头的文件执行过不能再修改,flyway会对内容进行对比,通过checksum字段,如果内容不一致,则执行不通过。R开头的文件则会再执行一次。