用于数据库结构的Flyway/Liquibase和用于数据库插入的DBUnit?

本文介绍了用于数据库结构的Flyway/Liquibase和用于数据库插入的DBUnit?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

我的应用程序具有以下情形:

• 1个生产服务器
• 1个测试服务器
• n开发计算机

对于数据库迁移，我们将Hibernate Schema Update用于Schema，并将DBUnit用于填充生产数据(在所有服务器/计算机上).架构更新完成后，我将为新架构生成一个新的DTD文件，因此可以重新导入DBUnit XML.该应用程序在启动时使用XML文件更新数据库(仅在开发和测试服务器/计算机上！)

当然，这种方法不是最优且脆弱的.所以我看着Liquibase和Flyway.两者似乎都是很好的工具，但是我没有得到的是:如何迁移数据?就我而言，我每周转储生产系统的数据并将其作为DBUnit XML文件添加到应用程序源控件中，因此所有开发人员都具有新"数据，而测试服务器也具有当前生产数据. >

我在Liquibase和Flyway上遇到的问题是，没有解决方案如何从数据库数据进行自动差异并自动生成迁移更改.

所以我的想法是通过以下步骤进行操作:

将Hibernate设置为验证而不是更新.

当需要更改STRUCTURAL数据库时，我将其添加到主要版本的迁移脚本中

迁移脚本中没有数据库插入.

基于新的数据库结构为DBunit生成新的DTD

从生产数据库生成DBUnit XML.

另一个想法是利用飞行路线JavaMigration并提供基于DBUnit的初始数据库转储.数据库数据的所有其他更改将在迁移脚本中处理.但是仍然存在问题:如何从当前的迁移脚本状态和生产数据库状态进行差异化处理?

如果有人可以给我提示如何处理我的情况，那将是很棒的事情:)

解决方案

如果您的目标是在DEV和TEST环境中使用PROD数据库的转储，我将:

• 配置数据库迁移工具以在应用程序启动时运行(Flyway和Liquibase均通过各自的API支持此功能)
• 将所有数据库结构迁移与应用程序打包在一起
• 从PROD中转储数据和结构

这样，当PROD数据库还原到DEV或TEST时，迁移工具的旧元数据表也将还原.

启动应用程序后，迁移工具将发现数据库结构已过时，并将其升级到最新版本.完成.

无需为此使用DBUnit.

I have the following scenario for my application:

• 1 Production Server
• 1 Test Server
• n Development Computers

For database migration we use Hibernate Schema Update for the Schema and DBUnit for filling in alle the production data (on all servers/computers). When the schema update is done I generate a new DTD File for the new schema, so I can do a fresh import of the DBUnit XML. The application updates the database at startup with the XML file (only on development and test servers/computers!)

Of course this approach is not optimal and fragile. So I looked at Liquibase and Flyway. Both seem to be great tools, but what I do not get is: How do I migrate the data? In my case, I dump the data of the production system once a week and add it to the applications source control as a DBUnit XML file, so all developers have "fresh" data and the test server has current production data, too.

The problem I see with Liquibase and Flyway is, that there is no solution how to do automated diffs from the database data and generate the migration changes automatically.

So my idea is the following with the following steps:

Set Hibernate to validate instead of update.

When a STRUCTURAL database change is needed, I add it to the migration script for the major version

No database inserts are in the migration script.

Generate a new DTD for DBunit based on the new database structure

Generate the DBUnit XML from the production database.

Another idea would be to utilize flyways JavaMigration and provide an initial Database Dump based on DBUnit. All other changes for database data will be handled in migration scripts. But still there is the problem: How to make diffs from the current migration script state and the production database state?

It would be awesome if anyone could provide me hints how to handle my scenario :)

解决方案

If your goal is to use dumps of the PROD database in DEV and TEST environments, I would:

• Configure the DB migration tool to run on application startup (both Flyway and Liquibase support this through their respective APIs)
• Package all the DB structure migrations together with the app
• Dump both data and structure from PROD

This way, when the PROD database is restored to DEV or TEST, the old metadata table of the migration tool is restored as well.

When the app starts, the migration tool will discover that the db structure is outdated and upgrade it to the newest version. Done.

No need to use DBUnit for this.