mysql - 如何最好地处理带有嵌入式数据库的 Flyway 以进行集成测试？

Question

我有一个最近开始使用 Flyway 的现有应用程序，它在大多数情况下运行良好。

我一直在为我的开发环境运行一个本地 MySQL 数据库，它与 QA 和 Prod 中使用的相匹配。

但是，我希望能够直接针对嵌入式数据库(例如 H2)运行至少一些集成测试。我曾天真地希望如此，因为 MySQL 似乎将(大部分？)它的特殊语句包装在 special comments 中。 (例如 /*! SET @foo = 123 */;)。

但是，当 Flyway 解析我的第一次迁移时，它似乎最终跳过了我所有的 CREATE TABLE 语句，因此它最终只应用了一些引用数据的 INSERT，但由于从未创建表而失败了。 .

我试过调高日志记录级别，但我没有看到任何迹象表明为什么 Flyway 刚刚跳过了我迁移的前 2228 行...

有没有人对如何最好地处理这种情况有任何建议？我试过随意地洒一些 /*! ... */ 对诸如 ENGINE=InnoDB 之类的内容进行评论，但 Flyway 似乎仍会跳过这些语句。

我是否最好使用特定于数据库的 flyway.locations 重新组织和复制大部分(如果不是全部)迁移，如 the FAQ 中所述？或者有什么方法可以让我做最少的更改，至少对我从用于基线迁移的现有数据库的初始 mysqldump 中得到的更改，以维护两个数据库的单一迁移？

或者...是否有推荐的方法来代替运行针对 MySQL 的集成测试？我遇到了MySQL Connector/MXJ , 但那个好像已经停产了...

Answer 1

老问题“没有SQL标准”。

Flyway 可能会跳过您的语句，因为它们包含 H2 无法理解的语法。请查看 H2 文档，找出 H2 CREATE TABLE 语法的哪一部分与 MySQL CREATE TABLE 语法不同。如果幸运的话，甚至可能有两个数据库都能理解的语法变体。

否则，您将不得不将 SQL 语句分隔到两个不同的位置。请记住，您可以同时告诉 Flyway 多个位置。因此，您可以拥有一个通用脚本的核心，并且只移动数据库特定文件中不同的部分。然后，您使用 common + H2 作为位置开始本地测试，并使用 common + MySQL 作为生产脚本。

如果您正在使用可以为您创建表的技术(如 Hibernate)，您可能希望在本地执行测试时不使用 Flyway，以避免必须处理两组迁移文件。只需让您的测试生成最新版本的数据库即可。这也可能有优势，因为它可能比稍后(比如几年后)运行大量迁移脚本要快得多。

您将不得不针对真实的 MySQL 数据库运行一些集成测试，因为您已经看到 H2 的行为可能完全不同。这样，您可能会考虑使用可用于数据库的任何备份解决方案，将一些数据旁加载到数据库中。这可能比尝试使用 Flyway 从头开始​​初始化数据库更快。 (再次完成您不想在测试之前运行多年的迁移脚本的行。)您可能只想测试最新的一组脚本，因为旧的脚本在新的时候确实有效(并且 Flyway 将确保它们没有被改变了)。