- flyway解决了什么问题
程序编写过程中,初始化数据库的sql,表结构变化sql,因为表结构变化所以有些老数据需要通过一些sql来处理。这样的sqll通常做法是卸载投产清单里面的。如果有人没按照投产清单来,这部分修改就会出错。
flyway 可以来管理投产清单里面的sql,通过版本和历史记录,在程序启动的时候对比上次已经执行过的历史版本,然后确定那些版本的sql 需要执行。 - flyway 怎么使用
- flyway使用的时候需要注意什么
flyway通过checksum字段来区分sql是否被修改过,正常我们的老的sql版本不应该直接修改,而是新建一个心得版本来修正老的版本,直接修改老版的sql会导致checksum和已经执行过的sql记录对应不上,程序启动报错 - checksum 是什么怎么计算的?
- R开头的sql不重复执行问题?
R开头的重复执行条件是里面的内容有修改导致checkSun变动,就会在下次重启的时候重复执行,所以R开的语句可以直接修改,但是一定要支持sql 重跑,只要和上个版本的checksum不同就会重新执行
V开头的不允许修改,只能在新的文件中追加修改 - flyway目录下面可以建立任意子目录,sql文件可以按照任意顺序放到子目录中,只有V后面的版本影响顺序,并且R开头的总是在后面V开头的后面执行
- 一些配置解释
flyway.baseline-description 对执行迁移时基准版本的描述.
flyway.baseline-on-migrate 当迁移时发现目标schema非空,而且带有没有元数据的表时,是否自动执行基准迁移,默认false.
flyway.baseline-version 开始执行基准迁移时对现有的schema的版本打标签,默认值为1.
flyway.check-location 检查迁移脚本的位置是否存在,默认false.
flyway.clean-on-validation-error 当发现校验错误时是否自动调用clean,默认false.
flyway.enabled 是否开启flywary,默认true.
flyway.encoding 设置迁移时的编码,默认UTF-8.
flyway.ignore-failed-future-migration当 读取元数据表时是否忽略错误的迁移,默认false.
flyway.init-sqls 当初始化好连接时要执行的SQL.
flyway.locations 迁移脚本的位置,默认db/migration.
flyway.out-of-order 是否允许无序的迁移,默认false.
flyway.password 目标数据库的密码.
flyway.placeholder-prefix 设置每个placeholder的前缀,默认${.
flyway.placeholder-replacementplaceholders 是否要被替换,默认true.
flyway.placeholder-suffix 设置每个placeholder的后缀,默认}.
flyway.placeholders.[placeholder name] 设置placeholder的value
flyway.schemas 设定需要flywary迁移的schema,大小写敏感,默认为连接默认的schema.
flyway.sql-migration-prefix 迁移文件的前缀,默认为V.
flyway.sql-migration-separator 迁移脚本的文件名分隔符,默认__
flyway.sql-migration-suffix 迁移脚本的后缀,默认为.sql
flyway.tableflyway 使用的元数据表名,默认为schema_version
flyway.target 迁移时使用的目标版本,默认为latest version
flyway.url 迁移时使用的JDBC URL,如果没有指定的话,将使用配置的主数据源
flyway.user 迁移数据库的用户名
flyway.validate-on-migrate 迁移时是否校验,默认为true - flyway 插件,感觉不是很必要,使用的话还要单独制定数据库地址,程序启动会读取datasource,插件不会需要配置flyway.url,flyway.user,flyway.password等

原创作者: u_15958225 转载于: https://blog.51cto.com/u_15958225/11802723