为什么要用Flyway
在日常开发中,我们经常会遇到下面的问题:
-
自己写的SQL忘了在所有环境执行;
-
别人写的SQL我们不能确定是否都在所有环境执行过了;
-
有人修改了已经执行过的SQL,期望再次执行;
-
需要新增环境做数据迁移;
-
每次发版需要手动控制先发DB版本,再发布应用版本;
-
其它场景...
由于项目需求的变化,或者前期设计缺陷,导致在后期需要修改数据库,这应该是一个比较常见的事情,如果项目还没上线,你可能把表删除了重新创建,但是如果项目已经上线了,就不能这样简单粗暴了,每次运维部署项目,还得手动执行一遍SQL文件。我们需要通过 SQL 脚本在已有数据表的基础上进行升级。
有了flyway,这些问题都能得到很好的解决。
使用了 Flyway 之后,如果再想进行数据库版本升级,就不用该以前的数据库脚本了,直接创建新的数据库脚本,项目在启动时检测了有新的更高版本的脚本,就会自动执行,这样,在和其他同事配合工作时,也会方便很多。因为正常我们都是从 Git 上拉代码下来,不拉数据库脚本,这样要是有人更新了数据库,其他同事不一定能够收到最新的通知,使用了 Flyway 就可以有效避免这个问题了。
所有的脚本,一旦执行了,就会在 flyway_schema_history (java www.fhadmin.cn ) 表中有记录,如果你不小心搞错了,可以手动从 flyway_schema_history 表中删除记录,然后修改 SQL 脚本后再重新启动(生产环境不建议)。
Flyway是如何工作的
Flyway工作流程如下:
1、项目启动,应用程序完成数据库连接池的建立后,Flyway自动运行。
2、初次使用时,Flyway会创建一个flyway_schema_history
表,用于记录sql执行记录。
3、Flyway会扫描项目指定路径下(默认是classpath:db/migration
)的所有sql脚本,与flyway_schema_history
表脚本记录进行比对。如果数据库记录执行过的脚本记录,与项目中的sql脚本不一致,Flyway会报错并停止项目执行。
4、如果校验通过,则根据表中的sql记录最大版本号,忽略所有版本号不大于该版本的脚本。再按照版本号从小到大,逐个执行其余脚本。
项目中使用Flyway
首先,在pom文件中引入flyway的核心依赖包:
1、引入核心依赖包:
<dependency> <groupId>org.flywaydb</groupId> <artifactId>flyway-core</artifactId> <version>5.2.4</version> </dependency>
这里使用5.2.4版本。经测试7.0.0版本与目前我们使用的sprin