entityMap|blocks|key|8h81t|text|简单的解决方案有一件很重要的事情-它将准确地跟踪您的dev数据库经过了什么过程才能达到它的当前状态，并在其他环境中准确地重播；因此，您不会因为没有正确地滚动更改而出错。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|8depi|另一个解决方案是为Flyway编写互补的撤销脚本(注意:付费功能)，这样你就可以上下浏览版本历史，直到你满意为止。|akqa|或者，这将在没有数据库重置的情况下工作:在DEV中：|dvoqk|V1__1.sql：CREATE+TABLE+blah+...|offset|length|style|CODE|fv8u6|V1__2.sql：ALTER+TABLE+blah+...|ds3kp|然后，当你高兴的时候，改变脚本以符合现实：|amsp7|V1__1.sql：CREATE+TABLE+blah+(new+version)+...|39q4c|V1__2.sql：<commented+out>|eih60|这可以在生产环境中运行，在开发环境中运行flyway+repair以重新对齐文件校验和。或者，以类似的方式，您可以维护两组脚本，一组用于开发，另一组用于生产，其中只包含您想要提升的更改。这两种方法都不能防止dev和prod无意中分离。正如评论中提到的，重置dev数据库是一件痛苦的事情，这本身就是一种味道，值得重新审视。|ekolm^0|0|0|0|A|L|0|A|K|0|0|A|Z|0|A|F|0|K|D|0^^$0|$]|1|@$2|3|4|5|6|7|8|X|9|@]|A|@]|B|$]]|$2|C|4|D|6|7|8|Y|9|@]|A|@]|B|$]]|$2|E|4|F|6|7|8|Z|9|@]|A|@]|B|$]]|$2|G|4|H|6|7|8|10|9|@$I|11|J|12|K|L]]|A|@]|B|$]]|$2|M|4|N|6|7|8|13|9|@$I|14|J|15|K|L]]|A|@]|B|$]]|$2|O|4|P|6|7|8|16|9|@]|A|@]|B|$]]|$2|Q|4|R|6|7|8|17|9|@$I|18|J|19|K|L]]|A|@]|B|$]]|$2|S|4|T|6|7|8|1A|9|@$I|1B|J|1C|K|L]]|A|@]|B|$]]|$2|U|4|V|6|7|8|1D|9|@$I|1E|J|1F|K|L]]|A|@]|B|$]]|$2|W|4|-4|6|7|8|1G|9|@]|A|@]|B|$]]]]

The simple solution has one big thing going for it - it will track exactly what your dev database went through to get to its current state, and replay that exactly in other environments; so you won't have mistakes due to not rolling up changes correctly.
Another solution is writing complementary undo scripts for Flyway (note: paid feature) so that you can navigate up and down the version history until you're happy with it.
Alternatively, this will work without database resets: in DEV:
V1_0_1.sql: <code>CREATE TABLE blah ...</code>
V1_0_2.sql: <code>ALTER TABLE blah ...</code>
Then when you're happy, change the scripts to match reality:
V1_0_1.sql: <code>CREATE TABLE blah (new version) ...</code>
V1_0_2.sql: <code>&lt;commented out&gt;</code>
This can be run in production, and in dev run <code>flyway repair</code> to re-align the file checksums. Or, in a similar vein, you can maintain two sets of scripts, one for dev and one for production which contains only the changes you want to promote. Neither of these will guard against dev and prod drifting apart unintentionally. As mentioned in the comments, the fact that resetting the dev database is a pain is in itself a smell and deserves revisiting.

entityMap|0|type|LINK|mutability|MUTABLE|data|url|https://www.red-gate.com/hub/product-learning/redgate-deploy/branching-and-merging-in-database-development-using-flyway|blocks|key|5bp93|text|作为对Julia答案的补充，问题中有趣的短语是“但由于这从来没有离开过开发，这似乎是一个糟糕的决定”。这是一个很好的观点:您的场景是您所做的更改测试失败，因此不应该出现在主要的迁移“叙述”中。如果您可以采用分支/合并策略，仅当您的分支上的单元和集成测试完成时才将迁移添加到“开发”分支，那么您就可以避免这种情况。|unstyled|depth|inlineStyleRanges|entityRanges|b5gon|我将在这里更详细地介绍这一点，Branching+and+Merging+in+Database+Development+using+Flyway。只要您可以为将数据库的分支版本构建到确切版本(分支点的版本)的分支创建初始迁移文件，Flyway就可以非常容易地管理这一点。如果在数据库的同一部分或依赖的数据库对象上存在并发开发，合并过程可能会很棘手，但对于数据库开发通常是这样的。|offset|length|c5tta^0|0|F|1M|0|0^^$0|$1|$2|3|4|5|6|$7|8]]]|9|@$A|B|C|D|2|E|F|N|G|@]|H|@]|6|$]]|$A|I|C|J|2|E|F|O|G|@]|H|@$K|P|L|Q|A|R]]|6|$]]|$A|M|C|-4|2|E|F|S|G|@]|H|@]|6|$]]]]

Just as a supplement to Julia's answer, the interesting phrase in the question is 'But since this never even left development that seems like a poor decision'. That's a good point: your scenario is that the changes you made failed testing, so shouldn't be in the main migration 'narrative'. If you can adopt a Branch/Merge strategy that adds the migration to the 'develop' branch only when unit and integration testing is complete on your branch, then you can avoid this.
I go into this in a lot more detail here <a href="https://www.red-gate.com/hub/product-learning/redgate-deploy/branching-and-merging-in-database-development-using-flyway" rel="nofollow noreferrer">Branching and Merging in Database Development using Flyway</a>. Flyway can manage this pretty easily as long as you can create an initial migration file for the branch that builds the branch version of the database to an exact version (the version at the point of branching). The merge process can be tricky if there are concurrent developments on the same part of the database or on dependent database objects, but that is generally true with database development..

entityMap|0|type|LINK|mutability|MUTABLE|data|url|https://spawn.cc/|1|https://flywaydb.org/documentation/spawn/firststeps/getting-started-containers.html|blocks|key|7bfbg|text|在Flyway上有一些文档，讨论如何使用Spawn通过创建临时数据库并为您处理这些数据库的管理来补充您的开发和测试环境。此页面的一部分explicitly+documents+"undoing+mistakes"+and+"restoring+to+previous+states"。|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|61k4v|这听起来就像你想要做的那样。|4qncs|这样，在您意识到迁移脚本应该是不同的之后，您可以运行spawnctl+reset+data-container+<your_container>将数据库恢复到原始状态。然后，您将能够使用已修复的迁移脚本再次运行flyway+migrate，就好像最初的错误迁移从未部署过一样。|style|CODE|ua0m|这应该比手动重置数据库状态容易得多，而且它的好处是让您准确地回到开始的位置。您也可以在开发过程中创建任意的保存点，这样您就可以重置回各种已知良好的状态。|4glr0^0|K|5|0|1V|22|1|0|0|Q|1A|2X|E|0|0^^$0|$1|$2|3|4|5|6|$7|8]]|9|$2|3|4|5|6|$7|A]]]|B|@$C|D|E|F|2|G|H|V|I|@]|J|@$K|W|L|X|C|Y]|$K|Z|L|10|C|11]]|6|$]]|$C|M|E|N|2|G|H|12|I|@]|J|@]|6|$]]|$C|O|E|P|2|G|H|13|I|@$K|14|L|15|Q|R]|$K|16|L|17|Q|R]]|J|@]|6|$]]|$C|S|E|T|2|G|H|18|I|@]|J|@]|6|$]]|$C|U|E|-4|2|G|H|19|I|@]|J|@]|6|$]]]]

There's some documentation over at Flyway discussing the usage of <a href="https://spawn.cc/" rel="nofollow noreferrer">Spawn</a> to supplement your development and testing environments by creating temporary databases and handling the management of those for you. One part of this page <a href="https://flywaydb.org/documentation/spawn/firststeps/getting-started-containers.html" rel="nofollow noreferrer">explicitly documents &quot;undoing mistakes&quot; and &quot;restoring to previous states&quot;</a>.
This sounds exactly like what you'd like to be able to do.
With this, after you've realised that a migration script should've been different, you can run <code>spawnctl reset data-container &lt;your_container&gt;</code> to take the database back to the original state. Then you'll be able to run <code>flyway migrate</code> once again with your fixed migration script as if the original erroneous migration never got deployed.
This should be considerably easier than resetting your database state manually, and has the benefit of taking you back to exactly where you started. You can make arbitrary save points as you go along developing too, so that you can reset back to various known-good states.

Let's say we're developing a feature and we have need for a new table. Awesome, we make a Flyway entry and we're off and running! Then, a few days later after some testing we realize wait, this column really should have been a blah, or we need a field we didn't anticipate to cache some value for performance, or for whatever reason our ivory tower version of the data model didn't match reality.
The simple solution would be to make another Flyway entry. But since this never even left development that seems like a poor decision. It really should be in the original build. But to do that I have to reset my database, which is a big waste of time for something so simple.
How should I be handling this on a day to day basis to protect my sanity and my time?

How to manage development of changes in Flyway?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

 假设我们正在开发一个特性，并且我们需要一个新的表。太棒了，我们进入Flyway，然后我们就可以开始运行了！然后，在一些测试后的几天后，我们意识到等待，这个列真的应该是废话，或者我们需要一个我们没有预料到的字段来缓存一些性能值，或者出于某种原因，我们的象牙塔版本的数据模型与现实不符。 简单的解决方案是创建另一个Flyw...

问如何管理Flyway变更的开发？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何管理Flyway变更的开发？EN