已关闭,此问题需要更focused。它目前不接受回答。
**想改善这个问题吗?**更新问题,使其只关注editing this post的一个问题。
上个月关门了。
Improve this question
我的目标是为现有应用程序启用模式和数据迁移。
这样的问题似乎已经被问过很多次了,但我想我的要求和情况不同。
由于我在这个领域没有经验,请允许我首先列出应用程序的架构和我的假设。
架构
该应用程序是一个多用户的企业桌面应用程序,具有后端服务器,可以持久化到任何主要数据库(MySql,PostgreSQL,SQL Server,Oracle DB等)。假设DB是内部部署的,由我们的客户维护。
使用的技术堆栈是相当常见的Hibernate+Spring+RMI/JMS-Combo。
目前,服务器通过以下方式完成迁移:
- 在服务器启动时,它检查最新的预期模式版本
1.如果大于当前版本,则开始迁移到下一个版本,直到current==latest:
1.创建新的数据库
1.加载(整个)最新模式(包含大量CREATE TABLE ...
的SQL脚本)
1.迁移数据(在Java类中使用2个JDBC连接到旧模式和新模式)
1.加载(所有)最新约束(包含大量ALTER TABLE ...
的SQL脚本)
这种迁移速度很慢,而且只能向前迁移。但这很简单。问题是,到目前为止,数据迁移中的模式脚本和查询一直使用MySQL语法和特性。
注意,migrate data的意思是:后端服务器将数据从旧模式复制到新模式,如果需要的话进行转换。此外,迁移过程在我们的客户端内部自动启动。这意味着,我们只能控制JDBC连接,但不能直接访问数据库,也不知道正在使用的特定数据库(MySQL,SQL Server等)。
我们的目标是用一个独立于数据库的迁移方案来替换或增强这个迁移方案。
假设和研究
StackOverflow 1234567:使用Hibernate的内置特性回答状态。然而,文档指出这不是production ready。此外,AFAICT,所有答案都只涉及模式迁移。
Liquibase:使用自定义DSL(XML/JSON/YAML/etc)来允许独立于数据库的模式迁移。
DBUnit:使用自定义XML-DSL捕获数据库状态的快照。无法重新创建架构版本1到版本2的快照。
flyway:原则上与Liquibase相同。但是不是独立于数据库的,因为SQL-SQL用于迁移。
JOOQ:JDBC之上的Java数据库独立查询DSL。与Criteria API相当,但没有JPA的缺点。原则上应该允许独立于数据库的数据迁移,但是,不有助于模式迁移。
像HQL、JPQL、Criteria API这样的JPA查询语言是不够的,因为
1.不能引用实体管理器未Map的表。例如连接表、元数据和审计表。
1.需要为Map保留Entity类的所有版本的副本。
提问
我意识到,这个问题现在,它将被驳回的意见为基础。
然而,我不一定要寻找这个问题的具体解决方案(我怀疑对于如此复杂的问题空间是否存在明确的解决方案),而是要验证我的假设。
也就是说,这是真的吗,
- Liquibase和Flyway主要关注模式迁移,而数据迁移则留给读者作为练习。
- 为了让Flyway支持多个不同的数据库,需要为每个数据库复制迁移脚本吗?
- 总的来说,数据库独立数据迁移的问题在企业Java中仍然没有得到解决。
即使我将合并Liquibase/Flyway与Jooq结合,我也不知道如何执行数据迁移,因为Liquibase/Flyway迁移数据库到位。旧数据库被销毁,并有机会将旧数据转换为新模式。
感谢您的关注!
1条答案
按热度按时间vu8f3i0k1#
让我们把它分解一点。你是对的,这在很大程度上是基于观点的,但这是我在我的经验中注意到的。
Liquibase和Flyway主要关注模式迁移,而数据迁移则留给读者作为练习。
您可以使用liquibase和flyway进行数据迁移。这是我经常做的事情。以我想将User表拆分为User和Address表为例。我写了一个迁移脚本,基本上就是一个SQL文件,用来创建新的Address表,并将所有相关数据复制到其中。
为了让Flyway支持多个不同的数据库,需要为每个数据库复制迁移脚本吗?
可能,flyway和liquibase更适合作为数据库版本控制工具。如果我的应用程序需要版本10的数据库,这些工具将帮助我达到这一点。同样,迁移脚本只是基本的.sql文件。如果你正在使用一些mysql的特定函数,那么这些函数只会进入迁移脚本,而不会在sql服务器上工作。
总的来说,独立于数据库的数据迁移问题在企业Java中仍然没有得到解决。
呃,我不确定这个。我同意这是一个问题,但实际上并不是一个大问题。在过去的8年里,我只写了ansi sql。它应该在任何地方都是便携式的。因此,理论上,我们可以将这些应用程序提升到不同的数据库中。JPA和各种实现有助于解决这些差异。根据你的项目是如何构建的,比如说一个应用程序,它的所有业务逻辑都在实现特定的sql函数中,那么这将是一个令人头痛的问题。如果您使用数据库进行CRUD,我认为这就是您应该使用它的全部目的,那么这不是一个大问题。
所以说,我认为你可能对Flyway和Liquibase有错误的想法。就像我前面说的,它们不是真正的“迁移工具”,而是数据库版本控制工具。有了一个有序的特定SQL迁移脚本列表,我可以保证我的数据库在任何版本的状态。我不确定这些是我用来“迁移”遗留的基于SQL Server的应用程序到基于PostGres的应用程序的工具。