有什么方法可以“压缩”飞行路线的迁移吗？
我们正在使用Flyway来迁移数据库模式，并且我们已经有了100多个迁移脚本。
一旦我们将多个迁移“压扁”为一个单一的第一版本迁移，在开发过程中，当我们删除并重新创建模式时，这就可以了。但在生产中，这是行不通的，因为Flyway无法验证迁移。
在这种情况下，我找不到任何文档或最佳实践。问题是文件数量不断增加，我不想每次都看到数千个迁移文件，本质上是如果生产已经在最新版本。我的意思是，那些版本号低于生产版本的迁移脚本与我们无关，如果我们能将这些文件压缩到一次迁移中，那就太棒了。
我们正在使用MySQL。
我们该如何处理？
共有1个答案
这难道不是重新设定基线所要做的吗？
我对flyway还是个新手，但我认为这就是它的工作方式。在相信我的话之前，请先测试以下内容。
删除schema_version表。删除迁移脚本。
运行flyway baseline（这将重新创建schema_version表，并将一条基线记录添加为版本1）
现在你可以走了。请记住，您将无法“迁移”到任何以前的版本，因为您已经删除了所有的迁移脚本，但这对您来说可能不是问题。
逐步解决方案：
-
null
-
我们正在使用Flyway迁移数据库模式，我们已经有100多个迁移脚本。 一旦我们将多个迁移“挤压”成一个单一的第一版本迁移，在开发过程中就可以了，因为我们删除并重新创建了模式。但在生产中，这是行不通的，因为Flyway无法验证迁移。 在这种情况下，我找不到任何文档或最佳实践。问题是，文件数量不断增加，我不希望每次都看到数千个迁移文件，基本上是在产品已经是最新版本的情况下。我的意思是，版本号低于生产
-
我们有一个用于填充表的迁移，但是由于我们刚刚开始开发，因此此数据经常更改。因此，我们想知道我们是否可以更新这样的迁移脚本，并要求flyway回滚它（以前的版本）并再次执行它（新版本）。事实上，如果这是可能的，也就是说，如果迁移是可变的，那么我们想象需要回滚并再次执行每个后续迁移，以确保它们没有受到影响。我们认为，这可以避免移徙在发展过程中的扩散。
-
我们使用Liquibase，现在在新项目中，我们必须使用Flyway。在liquibase中，迁移顺序在xml文件中，所以您可以指定什么是第一次迁移，什么是第二次迁移，它不依赖于名称。 所以，当一些开发人员添加新的迁移时，如果之前有人推动了新的迁移，那么他将在Git中遇到冲突，并且必须修复顺序。 这是如何在Flyway中实现的？如果并行添加迁移，如何控制顺序？
-
在类路径中：/db。迁移有迁移但flyway没有看到这一点，而是爱上了msg 2022-05-02 17:28:07.993INFO 45296 --- [ restartedMain]c. c. c. ConfigServiceProperty tySourceLocator：从服务器获取配置，地址为：http://localhost:8888/story2022-05-02 17:28:08.
-
我为命令行java迁移执行了以下步骤： < li >创建java文件 当我执行迁移逗号时，它会像 警告：无法解析位置类路径：db/迁移 请查看下面的附件图片，它实际上是罐子。我已经提取了更多信息。
-
目前，我们公司通过手动创建、分发和运行必要的SQL脚本来处理所有数据库模式更改。显然，这会导致各种机器偶尔更新和稀疏更新的问题。 我正在研究更现代的方法来解决这个问题，而Flyway现在是主要的候选人（尽管如果可以提出令人信服的论据，我们仍然愿意使用Liquibase）。 正常流程很简单，和宣传的一样简单，但是我们不知道如何正确处理冲突的迁移脚本。例如，不同个人分支（A和B）上的2名开发人员在不同