Flyway 的迁移前和迁移后脚本
我正在寻找一种在迁移之前和之后执行挂钩脚本的方法。 我有一堆视图和存储过程，希望过程是：
- 删除所有视图和存储过程。
- 运行迁移。
- 重建视图和存储过程。
这可确保对架构的任何更改都会反映在相关视图和存储过程中。步骤 (1) 和 (3) 将是 bash 脚本。
这在 Flyway 中可能吗？
I am looking for a way to execute a hook script before and after migration.
I have a bunch of views and stored procedures and would like the process to be:
- Drop all views and stored procedures.
- Run the migration.
- Rebuild views and stored procedures.
This insures that any change to the schema is reflected in related views and stored procedures. Steps (1) and (3) will be bash scripts.
Is this possible in Flyway?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
更新 2014-04-29： 现在，通过实现 FlywayCallback 接口，Flyway 3.0 可以实现这一点。
先前的回答
简短的回答是：不，目前还不行。
原因是：我在制定 Flyway 的初始设计时就考虑过这一点。不过，我对这方面的思考越多，我就越清楚这些前置和后置脚本也是迁移的一个组成部分，或者至少是迁移离不开的东西，如果它想要成功。因此我建议：
您甚至可以让 x.1 和 x.3 调用存储过程如果重复这些步骤，请为您完成工作以避免迁移之间的代码重复。
让 Flyway 负责执行对数据库结构的所有更改使整个事情变得更加简单，避免了不同技术的混合。
Update 2014-04-29: This is now Possible with Flyway 3.0 by implementing the FlywayCallback interface.
Previous answer
The short answer is: no, not at this point.
Here is the reason: I thought about this as well as I was laying down the initial design for Flyway. The more I thought about this aspect though, the more it became clear to me that these pre and post scripts are also an integral part of the migration, or at least something a migration can not do without if it wants to be successful. Therefore I would recommend to either:
You might even be able to have x.1 and x.3 call stored procedures that do the work for you to avoid code duplication between migrations if these steps are repeating.
Having Flyway take care of performing all changes to the database structure makes the whole thing more straightforward, avoiding a mix of different technologies.
要扩展 Axel 的响应：使用 sql 脚本的回调仅意味着将
beforeMigrate.sql（例如，这是包含迁移的目录中的一个关键字，Flyway 将在其他迁移脚本之前执行beforeMigrate.sql。甚至在schema_version被锁定之前。其他回调名称（例如
afterMigrate）在回调文档。To expand on Axel's response: callbacks with sql scripts simply means putting
beforeMigrate.sql(for instance, this is one keyword among others) in the directory containing the migrations, and Flyway will executebeforeMigrate.sqlbefore the other migration scripts. Even beforeschema_versiongets locked.Other callback names (e.g.
afterMigrate) are listed in the documentation for callbacks.您应该使用 Flyway 回调，例如：
https://flywaydb.org/documentation/concepts/callbacks#beforeEachMigrate
https://flywaydb.org/documentation/concepts/callbacks#beforeEachMigrate
另请参阅：
https://flywaydb.org/documentation/tutorials/callbacks.html
SQL 回调
挂钩 Flyway 生命周期的最方便方法是通过 SQL 回调。这些只是配置位置中遵循特定命名约定的 sql 文件：事件名称后跟 SQL 迁移后缀。
使用默认设置，Flyway 在其默认位置（命令行工具的/sql）中查找 SQL 文件，例如 beforeMigrate.sql、beforeEachMigrate.sql、afterEachMigrate.sql…
占位符替换的工作方式与它一样用于 SQL 迁移。
可选地，回调还可以包括描述。在这种情况下，回调名称由事件名称、分隔符、描述和后缀组成。示例：beforeRepair__vacuum.sql。
注意：在扫描 SQL 回调时，Flyway 还将尊重您配置的任何 sqlMigrationSuffixes。
Java回调
如果 SQL 回调对您来说不够灵活，您可以选择自己实现回调接口。您甚至可以在生命周期中挂钩多个回调实现。 Java 回调具有额外的灵活性，单个回调实现可以处理多个生命周期事件，因此不受 SQL 回调的约束
you should use flyway Callbacks like:
https://flywaydb.org/documentation/concepts/callbacks#beforeEachMigrate
https://flywaydb.org/documentation/concepts/callbacks#beforeEachMigrate
see also :
https://flywaydb.org/documentation/tutorials/callbacks.html
SQL Callbacks
The most convenient way to hook into Flyway’s lifecycle is through SQL callbacks. These are simply sql files in the configured locations following a certain naming convention: the event name followed by the SQL migration suffix.
Using the default settings, Flyway looks in its default locations (<install_dir>/sql) for the Command-line tool) for SQL files like beforeMigrate.sql, beforeEachMigrate.sql, afterEachMigrate.sql, …
Placeholder replacement works just like it does for SQL migrations.
Optionally the callback may also include a description. In that case the callback name is composed of the event name, the separator, the description and the suffix. Example: beforeRepair__vacuum.sql.
Note: Flyway will also honor any sqlMigrationSuffixes you have configured, when scanning for SQL callbacks.
Java Callbacks
If SQL Callbacks aren’t flexible enough for you, you have the option to implement the Callback interface yourself. You can even hook multiple Callback implementations in the lifecycle. Java callbacks have the additional flexibility that a single Callback implementation can handle multiple lifecycle events, and are therefore not bound by the SQL callback