有关如何编写工具以将数据库数据从支持 Hibernate 的 Java 应用程序的一个版本迁移到下一个版本的书籍/文章/建议

发布于 2024-09-16 10:30:49 字数 491 浏览 1 评论 0原文

我们开发并支持使用 Hibernate 作为对象关系映射工具来将 Java 对象保存到数据库中的应用程序。不幸的是,OurApp 1.0 和 OurApp 2.0 之间的对象模型以及数据库模式发生了一些变化。因此,我们希望编写一个自动化工具,将数据从使用 OurApp 1.0 的客户数据库迁移到模式与 OurApp 2.0 匹配的新数据库。

我们正在考虑创建一个工具,每个 Java 类都有两个版本。例如,我们可能有一个 Java 类 MyObject_1_0 与 OurApp 1.0 中出现的 MyObject 类匹配,还有一个与 OurApp 2.0 中出现的 MyObject 类匹配的 MyObject_2_0。然后,我们将编写知道如何将 MyObject_1_0 转换为 MyObject_2_0 的代码。

然而,这不是我以前做过的事情,我想知道这是否是最好的方法。如果我能回顾一些关于最佳实践和常见陷阱的文献和研究,那就太好了。在我们研究最有效的方法时,有人可以推荐我可能觉得有用的书籍或文章吗?

谢谢!

We develop and support and application that uses Hibernate as an Object-Relational Mapping tool to persist our Java objects into the database. Unfortunately, there have been some changes in object model, and thus the database schema, between OurApp 1.0 and OurApp 2.0. So, we would like to write an automated tool to migrate the data from databases of customers using OurApp 1.0 to a new database with a schema matching OurApp 2.0.

We were thinking of creating a tool that has two versions of each Java class. For example we might have a Java class MyObject_1_0 that matches the MyObject class as it appears in OurApp 1.0 and a MyObject_2_0 that matches the MyObject class as it appears in OurApp 2.0. We would then write code that knows how to convert a MyObject_1_0 to a MyObject_2_0.

However, this isn't something I've done before and I'd like to know if this is the best approach. It would be nice if I could review some literature and research on best practices and common pitfalls. Can anyone recommend books or articles that I might find useful as we research the most effective ways to do this?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

撩动你心 2024-09-23 10:30:49

我们正在考虑创建一个工具,每个 Java 类都有两个版本。例如,我们可能有一个 Java 类 MyObject_1_0 与 OurApp 1.0 中出现的 MyObject 类匹配,还有一个与 OurApp 2.0 中出现的 MyObject 类匹配的 MyObject_2_0。然后,我们将编写知道如何将 MyObject_1_0 转换为 MyObject_2_0 的代码。

正如 Peter 所建议的,我确实会考虑使用数据库迁移工具,这应该会更加高效,并且最终的工作也会更少,正如我们将看到的。由于目标数据库不在您的控制之下,我会寻找一种允许以与数据库无关的方式描述更改的东西,例如 liquibase,它使用 XML。

支持liquibase的另一个论点是它提供了Hibernate 集成,这是您场景的杀手级功能:它可以通过将实体(XML 或注释)的新映射与 <旧数据库。即使结果需要一些调整,这也会大大简化工作。从文档中:

Hibernate 集成(自 1.6 起)

LiquiBase-Hibernate 是一个
替换 Hibernate 的 hbm2ddl
功能。

LiquiBase 相对于 hbm2ddl 的优势

虽然 hbm2ddl 通常可以工作,但它是
基本上是一个数据库差异工具和
因此存在所有问题
与数据库差异工具相关。

LiquiBase-Hibernate 集成
记录所需的数据库更改
通过您当前的 Hibernate 映射到
更改日志文件,然后您可以
之前根据需要检查并修改
执行。开发流程

将 Hibernate 与 LiquiBase 结合使用包含以下步骤:

  1. 对 Hibernate 映射对象进行必要的更改
  2. 在 Hibernate 配置文件和
    开发数据库(参见示例
    如下)
  3. 检查并修改新的变更集(如果需要)
  4. 使用新的更改更新您的数据库

您可以为所有受支持的数据库提供 SQL 脚本,或者简单地将工具包装在某些 Ant 构建中。

这也是在您的开发过程中采用此类工具的机会。

We were thinking of creating a tool that has two versions of each Java class. For example we might have a Java class MyObject_1_0 that matches the MyObject class as it appears in OurApp 1.0 and a MyObject_2_0 that matches the MyObject class as it appears in OurApp 2.0. We would then write code that knows how to convert a MyObject_1_0 to a MyObject_2_0.

As suggested by Peter, I would indeed consider using a database migrations tool instead, this should be much more efficient and also less work at the end as we'll see. And since the target database isn't under your control, I would look for a something allowing to describe changes in a database agnostic way, like liquibase, which uses XML.

Another argument in favor of liquibase is that it provides Hibernate integration which is a killer feature for your scenario: it can generate a migration script by comparing the new mappings of your entities (XML or annotations) against an old database. Even if the result needs some tweaking, this should highly simplify the work. From the documentation:

Hibernate Integration (Since 1.6)

The LiquiBase-Hibernate is a
replacement to Hibernate's hbm2ddl
functionality.

Advantages of LiquiBase over hbm2ddl

While hbm2ddl works in general, it is
basically a database diff tool and
therefore has all the problems
associated with database diff tools.

The LiquiBase-Hibernate integration
records the database changes required
by your current Hibernate mapping to a
change log file which you can then
inspect and modify as needed before
executing. Development Process

Using Hibernate with LiquiBase consists of the following steps:

  1. Make needed changes to your Hibernate-mapped objects
  2. Run diffChangeLog between your Hibernate config file and your
    development database (see examples
    below)
  3. Inspect and modify new change sets (if needed)
  4. Update your database with the new changes

And you could either provide SQL script for all supported database or simply wrap the tool in some Ant build.

This is also an opportunity to adopt such a tool in your development process.

逆光飞翔i 2024-09-23 10:30:49

我首先建议查看 dbMigrateliquiBase 或许还有 dbMaintain。

这些库、工具是专门为进行架构迁移而构建的。他们使用不同的方法。

它们可能是您解决方案的一部分,甚至本身就足够了。

I would first recommend to look at dbMigrate and liquiBase and maybe also dbMaintain.

These libraries, tools are purpose build to do schema migrations. They use different approaches.

They may be part of your solution, or even be sufficient in themselves.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文