# 使用flyway解决增量SQL问题

### 1. 增量SQL在服务模块中的位置
classpath: db

### 2. 增量SQL的命名规则(与官方配置一样)
![img.png](img.png)

Prefix 可配置，前缀标识，默认值 V 表示 Versioned， R 表示 Repeatable， U 表示 Undo。
Version 标识版本号, 由一个或多个数字构成，数字之间的分隔符可用点 . 或下划线 _。
Separator 可配置，用于分隔版本标识与描述信息，默认为两个下划线 __。
Description 描述信息，文字之间可以用下划线 _ 或空格 分隔。
Suffix 可配置，后续标识，默认为 .sql。

<b>特殊说明：版本号使用服务模块的版本号再加一位，共4位数，比如：Bi模块的版本号4.0.1，则定义增量SQL文件时，命名为：V4.0.1.0__20241108_biz.sql</b>

可选项： 分隔符后面可以加上日期便于查看增量sql的日期，以及业务属性也可以放上。

### 3. flyway的sql变更历史表

每个服务模块都有一个对应的SQL变更历史表，名字以flyway_开头。比如：bi模块的spring.application.name=geometry-bi/gmetry-bi，则它的表名为：flyway_bi

### 4. 【切记】SQL脚本内容一定要加上数据库名.表名

### 5. 关闭执行flyway脚本迁移【默认开启】
blade.flyway.enabled=false

注：在开发环境或测试环境，有可能需要关闭脚本执行。 因为：开发过程中，已经手动在数据库执行了表变更语句

### 6. 升级platomix-gmetry-framework为2.5.1

### 7. 执行脚本异常修复
 flyway脚本迁移不支持事务回滚的。   
当执行某行SQL脚本失败(该SQL写的有问题)时，项目会停掉，并且该行脚本之前的SQL已执行成功。如何修复并重新启动项目？  
首先，一定要确保提交上去的脚本是正确的。 当遇到flyway执行SQL脚本失败项目宕掉时，flyway同样会把该记录存入变更历史表。如果手动修复SQL脚本正常，该脚本也不会执行(项目框架默认关闭了flyway的sql脚本校验)。  
 <b>修复方式（较麻烦）：</b>  
（1）需要新建一个版本号大于当前文件的sql脚本，把包括该行之后的记录都放进去；  
（2）执行手动执行SQL命令更新sql变更历史表中错误版本号的记录。  
 
``` 
UPDATE flyway_[项目名] SET success = true WHERE version = '[failed_version]';

比如：bi模块的V4.0.1.0__20241108_biz.sql有执行失败，则执行SQL：UPDATE flyway_bi SET success = true WHERE version = '4.0.1.0';
``