生成Hibernate hbm xml文件&来自现有数据库模式的实体类 [英] Generating Hibernate hbm xml files & entities classes from existing DB schema

问题描述

我如何生成Hibernate hbm xml文件&实体类从现有的数据库模式？

解决方案

我非常高兴地使用Hibernate Tools（在他们的网站上给出的例子）。
下面，我详细介绍了我的特定的，高级的和有趣的（我认为）用例。

---

其实，我在我们的大型项目中遇到了一个有趣的挑战（接近800个表格，数据库驱动团队）

• 新表格会一直到达，所以我可以从数据库
  中生成它们（使用HibernateTools并生成带注释的实体）（我们现在实际上正在使用另一个进程......）
  

• 但是大多数表不是新的，我已经有了java实现和.hbm.xml。
  两者有时都是从它们最初生成的数据库中进行修改的，所以不可能通过担保不会破坏任何东西来重新生成它们。 我需要迁移实体，尽可能少地更改（即只有注释）！
  
  

  
  
  • 这也需要很快，因为我们典型的旧实体大约有100个成员（自己的数据库列，加上来自反向外键的实体集合！）。注意：两个实体无法用生成的完全构造函数进行编译，他们打破了256个参数的限制！但是，尽管这个构造函数无用，但谁还记得256个参数的顺序，所以我删除了它。

  
  
  • 我也想将我的集合迁移到通用集合（除了
    

对于映射迁移，我使用Hibernate Tools（根据需要定制，模板和代码）如下：

• 信息的来源是.hbm.xml文件和hibernate.cfg.xml文件
  
  注意：我必须首先解压缩hibernate.cfg.xml，以取代以前的spring bean包含列表。但是这对于Squirrel等数据库工具也很有用，它可以使用它来启用HQL完成......

生成的输出是X2.java文件（对于X.java类，在同一个包中）只包含字段，获取者和注解
（没有setter或构造函数）（泛型集合）

我会使用Eclipse编译器（错误duplicate ...）来仔细检查我的编辑，使其更快，更不易出错（错误不是一种选择，我们有许多客户正在生产！）。对于每个迁移的类，我将从生成的类复制到现有的类：

• 更改persistence.cfg.xml以使用类而不是。 hbm.xml
  
• 在课程名称前剪切并粘贴@Entity
  
• 剪切并粘贴所有在现有字段后面设置字段，只删除现有字段一个编译错误（结果是我现在拥有带有泛型集合的字段）
  
• 在现有setters之后剪切并粘贴所有getter（这是类的其余部分）


• 打开大纲视图，只显示不以set开头的公共动态方法，按字母顺序排序
  
• 检查每个没有错误的getter（调查是否出错，或者从...开始删除）
  
• 在大纲视图之后，仅考虑错误的方法，对于每个getter按顺序：
  删除方法的第二个实例，将其注释复制到第一个实例
  （使用大纲视图导航）（t的顺序）他在课堂上的方法被保留下来，这对CVS的历史非常重要，特别是向不信的人证明他们的移植并没有破坏他们的代码，这已经被破解了！）。


• ...有些细节还有待进一步讨论......

好奇的是，本月我们接近200个带注释的实体： - ）。
典型的100字段实体需要大约30分钟的工作才能迁移。
剩下的600个实体只剩300个小时完成这个剪贴！ ; - ）

How can I generate Hibernate hbm xml files & entities classes from an existing DB schema?

解决方案

I've used Hibernate Tools (examples given on their site) with much pleasure. Below, I give details on my specific, advanced and interesting (I think) use case.

---

Actually, I was facing an interesting challenge on our big project (approaching 800 tables, database driven team)

• New tables would keep arriving, so I could generate them from the database (using HibernateTools, and producing Annotated Entities)(we're actually using another process right now ...)

• But mosts tables were not new, I already had the java implementations and the .hbm.xml. Both had sometimes been modified from the DB they were originally generated with, so it was impossible to re-generated them with the guaranty not to break anything. I needed to migrate the Entities, changing as little as possible (that is, only the annotations) !

  • This needed to be fast also, because our typical old entities have around 100 members (own db columns, plus entity collections coming from reverse foreign keys!).

    Note : Two entities couldn't compile with a generated full-constructor, they broke the 256 parameters limit ! But I though this Constructor was useless anyway, who could remember the order of 256 parameters, so I removed it.

  • I also wanted to migrate my Sets to generic ones (except the setter I didn't bother with for now).

For the mapping migration, I used Hibernate Tools (customized as needed, template and code) as follow:

• the source of the information was the .hbm.xml files, with the hibernate.cfg.xml file

  Note : I had to extract the hibernate.cfg.xml first, replacing the spring bean that used to contain the list. But this was also useful for db tools such as Squirrel, that could use it to enable HQL completion...

• the generated output was X2.java files (for X.java class, in the same package) containing only the fields, getters and annotations (no setters or constructors)(generic Sets)

I would use the Eclipse compiler (error "duplicate ...") to double-check my editing, to make it faster and less error-prone (mistake was not an option, we have many client in production !). For each migrated class, I would copy from generated to existing class :

• change persistence.cfg.xml to use the class instead of the .hbm.xml
• cut and paste @Entity before class name
• cut and paste all Set fields after existing fields, delete only the existing ones that have a compile-error (the result is that I now have fields with generic Sets)
• cut and paste all getters (which is the rest of the class) after the existing setters
• open the outline view, showing only public dynamic methods not starting with 'set', sorted alphabetically
• check each getter that has not error (investigate if something went wrong, or it had been dropped since ...)
• following the outline view, considering only erroneous methods, for each getter in order : delete the second instance of the method, copy its annotations to the first instance (navigation using the outline view)(the order of the methods in the class is preserved, which has been important for CVS history, notably in proving to unbelievers that the migration didn't break their code, it was already broken before !).
• ... some details left for further discussion ...

For the curious, this month we're close to 200 annotated entities :-). A typical 100 fields entity requires about 30 minutes work to migrate. Only 300 hours left to finish this cut'n paste for the remaining 600 entities ! ;-)

这篇关于生成Hibernate hbm xml文件&来自现有数据库模式的实体类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！