由于版本问题，我们在Sping Boot 3-Environment中从Flyway切换到Liquibase。由于我们仍然处于非生产环境中，我们的数据库模式正在快速变化，我们不关心数据丢失。然而，由于我们正在更改模式，我们不想引入新脚本，而是只要我们不生产就更改初始脚本。
在使用Flyway时，我们将使用选项clean-on-validation-error，以便仅在必须应用模式中的更改时删除现有数据库。
对于Liquibase，我们只发现了drop-first选项，这会导致每次重启应用程序时都要重置数据库，即使没有新版本部署，而是让kubernetes重新启动pod。
当我说“我们不关心数据丢失”时，我指的是在测试应用程序时产生的那些数据。当数据库被清空时，有很多“核心数据”必须由批处理作业生成。
我的问题是：有没有一种方法可以使用Sping Boot 3和Liquibase来模拟Flyway的clean-on-validation-error的行为？
我们所做的：阅读docs.liquibase.com上的文档，尝试多个liquibase属性
1条答案
按热度按时间m528fe3b1#
我已经有一段时间没有与Liquibase密切合作了，但这里有一些想法。
我相信您描述的用例并不常见，因为代码往往会频繁更新和部署，并且在比本地容器更高的 * 任何 * 环境层中，现有变更中的变更可能（而且很可能 * 会 *）给团队带来问题和时间损失。使变更集原子化，可逆和不可变是Liquibase的最佳实践。否则，您可以花费时间执行手动回滚，将修复应用到changeset checksums，并运行重新部署。
但你仍然有选择（其中一些是值得做的）：
update之前运行validate命令（顺便说一句，我强烈建议使用update-testing-rollback代替），仅在验证失败的情况下添加applydropFirst参数;dropFirst应用于部署到某些环境或属于“我们不关心数据丢失”类别的上下文;Liquibase是非常灵活的，但我怀疑它是否可以做你想要的只有一个参数。我可能错过了一些东西，虽然。