问题标签 [flyway]

持续交付中的生产关系数据库（和模式）迁移模式是什么？

在许多传统开发中，DBA 从当前发布周期中创建的许多较小脚本中安排了一个大迁移脚本。但是在 CD 中，开发人员可能希望现在将更改推送到生产环境，而不是等待与其他脚本一起编译它们。

我知道 rails-migration 但对我来说使用原始 sql 脚本看起来更合理。

我还看到过像flyway这样的工具来管理迁移，但我还没有看到很多人在生产中使用它们。这就是为什么我想知道这里的常见做法是什么。

我考虑将 Flyway 与 postgresql 一起使用。

当迁移失败时，我是否需要手动回滚它或者它是否可以与 postgres 一起使用 ootb？在失败后是否继续运行以下迁移？

像 liquibase 和 flyway 这样的工具当然可以轻松升级您的数据库。我没有弄清楚的是如何最好地处理发布分支和主干上发生的更改。

一个例子：

我在产品中的代码是 2.5 版，并且位于发布分支上。与此同时，开发人员已经开始开发基于主干的 3.0 版本。

在生产中发现了一个错误。制作了一个数据库更改脚本（2.5.1）并提交到发布分支。必须将相同的更改脚本合并回主干（3.0.1？）。

版本 3.x 已发布到野外生产数据库中，与 2.5.1 相比已经有了变化。升级可能会失败。

相反，如果我从头开始创建一个数据库，如果我使用的是仅向前策略，我会发生两次相同的更改（2.5.1 和 3.0.1）。

其他人如何处理这种情况？

OUR SYSTEM

We are trying to put migrations as .sql files under version control. Developers would write a VN__*.sql file, commit to version control and a job that runs every 5 minutes would automatically migrate to a Dev and Test database. Once the change proved to not cause problems, someone else would run a manual job to run the migration on Production.

MY PROBLEM:

I had a demo migration that created a few tables. I checked V4__DemoTables.sql into version control on my PC.

On our Linux box a job that runs every 5 minutes extracted the new file from version control, then ran the flyway.sh file. It detected the file and executed it.

But the .sql file had a typo. And we are using Neteeza which has problems with flyway automatically wrapping a migration in a BEGIN TRAN ... END TRAN. So the migration created 2 tables, then aborted before the third.

No problem I thought. I dropped the 2 tables that the .sql file did create. Checked V4__ out of version control, fixed the typo and re-submitted it.

Five minutes later the update was extracted but flyway complains that the checksum does not match. So it will NOT run the updated V4__DemoTables.sql file.

How do I get flyway to accept the updated file and update the checksum in the SCHEMA_VERSION file in case of a typo?

Reading the docs it seems like the developers suggest I should have created a new V4_1_DemoTables.sql file with the fix's. But this would have collided with the commands in the V4__ file so this seemed wrong.

So here is what the docs imply I need to do:

• Leave V4__ as a 'successful' migration according to the SCHEMA_VERSION table.

  Create V4_1_ to delete the tables that were created before the typo line in V4__.

  Create V4_2_ which has the typo fix from the original file to do all the real work.

Is this correct?

Flyway 提供了一个 oracle pl/sql 解析器，那么是否可以使用 pl/sql 转储 (.pde) 进行迁移？

我目前正在使用 flyway 1.7 和 jBoss 7。当 flyway 迁移运行时，如果完全迁移的时间超过 5 分钟，jBoss 显示它会使事务超时，但即使在那之后 flyway 继续迁移，最终我最终得到了完全迁移DB 但由于事务超时而导致部署失败。我最近还意识到，如果我在迁移运行时尝试关闭 jBoss，迁移不会受到影响并且它们会继续执行。这是一种可取的行为吗？flyway 是否在她自己的某种被阻止的事务下运行迁移，我对此无能为力？

问候， D

有时 createEntitymanagerFactory 可能需要一段时间，特别是在需要创建数据库时。

我正在为我的数据库使用 Flyway，并开始在迁移过程中发现问题。查看日志似乎我正在尝试在创建表之前进行迁移。例如

JPA 设置为创建表。当我在 JPA 中启用日志时，它显示上述错误发生在 JPA 完成创建数据库之前。

有没有办法监听 JPA 数据库以知道它何时准备就绪？我只找到实体本身的侦听器，但没有找到 PersistenceManager 生命周期的侦听器。

我用 flyway-maven-plugin 做了一些实验。我没有空数据库，所以我需要一个初始 ddl 脚本。我按照 flyway wiki 中的说明进行操作：

我将名为V1__Base_Migration.sql的 sql 脚本放在src/main/resources/db/migration中。

flyway-maven-plugin 的配置如下所示：

当我调用mvn install flyway:initcmd并查看数据库中的运行时，我可以找到flyway的版本表，但找不到该表，其ddl在sql脚本中。

当我查看 Maven 的调试日志时，我找不到任何关于运行 sql 脚本的提示。

我做错了什么吗？如果有人可以给我一个提示，那会很酷，我做错了什么。

您可以在 [github] (https://github.com/skosmalla/flyway-maven-test) 中找到整个 Maven 测试项目

最好的祝福，

桑德拉

我最近才发现Flyway，在阅读和搜索它时，我遇到了以下博客文章：数据库模式演变与模式版本控制。

所以我想知道：

• 它所说的是否仍然正确（甚至在当时是正确的）
• 在使用flyway时应该如何处理这种情况。

编辑：

常见问题解答简要讨论了这一点（没有为上述问题提供解决方案）。

在不重复代码的情况下，更新 schema_version 表并在 flyway 中执行修改后的 PL/SQL 包/过程的更好方法是什么？

我的示例需要为每个 PL/SQL 代码修改创建一个类文件

AbstractMigration 类执行db/update文件夹中的文件：

有没有更好的方法来执行 PL/SQL 代码？