飞行路线迁移冲突处理
目前，我们公司通过手动创建、分发和运行必要的SQL脚本来处理所有数据库模式更改。显然，这会导致各种机器偶尔更新和稀疏更新的问题。
我正在研究更现代的方法来解决这个问题，而Flyway现在是主要的候选人（尽管如果可以提出令人信服的论据，我们仍然愿意使用Liquibase）。
正常流程很简单，和宣传的一样简单，但是我们不知道如何正确处理冲突的迁移脚本。例如，不同个人分支（A和B）上的2名开发人员在不同的迁移（MigrationA和MigrationB）中将相同的列添加到表中。分支B上的开发人员意识到，在他已经在数据库上运行MigrationB后，就没有必要了。不幸的是，此时损坏已经造成，并且已经将一个条目写入数据库B中的schema_version表。由于Flyway不支持回滚，在这种情况下，什么是适当的响应？
从历史上看，我们尽可能避免删除/重建我们的数据库，但是一旦你使用Flyway，这种心态是否已经过时了？我们是否应该彻底创建 DeveloperData 脚本，以便在出现这些问题之一时随时删除数据库？在我开始告诉同事们我们需要开始丢弃我们的数据库之前，我想确保我以正确的方式接近这一点。
感谢任何特定输入的答案或更多关于人们如何成功转换到Flyway的一般解释/示例。
共有1个答案
你是正确的。
DEV数据库可以也应该被视为一次性的，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/迁移 请查看下面的附件图片，它实际上是罐子。我已经提取了更多信息。
-
我们有一个用于填充表的迁移，但是由于我们刚刚开始开发，因此此数据经常更改。因此，我们想知道我们是否可以更新这样的迁移脚本，并要求flyway回滚它（以前的版本）并再次执行它（新版本）。事实上，如果这是可能的，也就是说，如果迁移是可变的，那么我们想象需要回滚并再次执行每个后续迁移，以确保它们没有受到影响。我们认为，这可以避免移徙在发展过程中的扩散。
-
我更改了一个错误的flyway脚本，这使我的迁移处于错误状态(我有5个脚本版本，但当我运行我的应用程序时，它从第4个开始，并得到一个错误“反应已经存在”)。我尝试从flyway cli使用clean，但它没有完全解决问题...此外，当我尝试将我的分支推送到git时，CI/CD管道将无法进行迁移。既然我在开发环境中，全部删除迁移脚本会是一个可怕的想法吗？删除所有脚本是否允许我在开发环境中“从头开始”
-
有没有办法告诉flyway在不应用迁移的情况下重新创建flyway表。例如，查看迁移文件夹中的脚本，假设它们都已应用，并简单地确保flyway表包含所有脚本。 我们的方案是，我们不允许在生产和（ISO;银行、认证）原因。规则说我们需要完全删除表。因此，当我们从生产副本重置测试环境时，我们需要重新创建飞行道表。现在，我们从现有的测试环境中复制和粘贴，但有时这与生产不同步，并且会发生各种问题。 因此，