我的项目包含很多对象，例如视图和存储过程，这些对象经常更改。现在我必须在每次更新时创建新的 SQL 脚本，其中包含已更改对象的完整源代码，尽管我实际上只更改了几行。它会导致大量代码重复，而且我还发现很难查看这些更改。
我希望每个对象（如视图或过程）只有一个实际版本的 SQL 脚本，并在每次重新部署数据库时重新创建这些对象。因此，我可以更改现有的源文件（如在 Java 或 C 编程中），而不是在每次需要更改视图或过程时创建新的更新。
每次使用 Flyway 迁移数据库时，是否有可能执行一些脚本？
问问题
157 次
2 回答
1
我不确定为什么会有如此多的反对票，这是一个完全可以理解和有效的问题。也许是因为它非常类似于这个悬而未决的问题： Migrating Stored Procedures with Flyway
我们现在实际上开始反对这个问题。我们一直在使用 flyway 进行开发和测试（并且喜欢它）。但是我们已经到了必须开始使用 procs/triggers/views (p/t/v's) 的地步，并且我们之前的操作方式与我们必须使用 flyway 之间的根本脱节正在开始成为一种压力。
以前，对于给定的数据库对象（假设它是一个过程），会有一个源文件。如果您需要更改 proc 'n' 次，您的 VCS 中将有相同文件的 'n' 个版本。Diff 工具工作得很好，IDE 都明白这一点，合并检测两个在不同分支中工作的开发人员何时对 proc 等进行更改等等。你知道，老派。
但是使用 flyway，任何一个具有“n”个更改的 proc 现在都分散在“n”个文件中。而不是“一个文件中的一个对象具有'n'个版本”，您有“一个对象在'n'个文件中，每个文件都有一个更改”。如果我想知道 proc 的更改历史，我现在需要在我的 IDE 中对任何“proc_name”实例进行文本搜索。VCS 对此一无所知。开发人员每个人都可以在自己的分支中进行迁移，每个分支在部署时都会成功，但会留下缺少更新的 proc。
我说这些并不是为了抱怨 flyway，我完全意识到这不是一个简单的领域。我几乎会说这是无法解决的（通过飞行方式）。
我们正在计划如何处理这个问题，我很想知道其他人是如何处理它的。
于 2013-07-03T21:11:43.110 回答
-1
Flyway 4.0 现在支持可重复迁移。只需将不带任何版本信息的以“R”开头的 sql 文件添加到迁移文件夹：
R__Blue_cars.sql
您必须确保脚本可以重复迁移。这通常由 DDL 语句中的“CREATE OR REPLACE”子句完成。
于 2017-03-14T09:05:12.790 回答