实际上,我在我们的大项目上遇到了一个有趣的挑战(接近800个表,数据库驱动的团队)

>新表将继续到达,因此我可以从数据库生成它们
(使用HibernateTools,并生成Annotated Entities)(我们现在实际上正在使用另一个进程……)
>但是大部分表都不是新的,我已经有了java实现和.hbm.xml.
两者有时都是从它们最初生成的数据库中修改过来的,因此不可能在保证不重新生成的情况下重新生成它们.我需要迁移实体,尽可能少地改变(即只有注释)！

>这也需要快速,因为我们典型的旧实体有大约100个成员(自己的db列,加上来自反向外键的实体集合！).

注意：两个实体无法使用生成的完整构造函数进行编译,它们打破了256个参数限制！但是我虽然这个构造函数无论如何都没用,谁能记住256个参数的顺序,所以我把它删除了.
>我也想将我的集合迁移到通用集合(除了我现在没有打扰的setter).

对于映射迁移,我使用了Hibernate Tools(根据需要自定义,模板和代码)如下：

>信息的来源是.hbm.xml文件,带有hibernate.cfg.xml文件

注意：我必须首先提取hibernate.cfg.xml,替换用于包含列表的spring bean.但这对于像Squirrel这样的数据库工具也很有用,它可以用它来实现HQL的完成……
>生成的输出是X2.java文件(对于X.java类,在同一个包中),只包含字段,getter和注释
(没有setter或构造函数)(通用集)

我会使用Eclipse编译器(错误“重复…”)来仔细检查我的编辑,使其更快,更不容易出错(错误不是一个选项,我们有许多客户端在生产！).对于每个迁移的类,我将从生成的类复制到现有的类：

>更改persistence.cfg.xml以使用该类而不是.hbm.xml
>在课程名称前剪切并粘贴@Entity
>在现有字段之后剪切并粘贴所有Set字段,仅删除具有编译错误的现有字段(结果是我现在具有包含泛型集的字段)
>在现有的setter之后剪切并粘贴所有getter(这是该类的其余部分)
>打开大纲视图,仅显示不以“set”开头的公共动态方法,按字母顺序排序
>检查每个没有错误的吸气剂(调查是否出现问题,或者是否因为……而被丢弃)
>按照大纲视图,仅考虑错误的方法,按顺序为每个吸气剂：
删除方法的第二个实例,将其注释复制到第一个实例
(使用大纲视图导航)(保留了类中方法的顺序,这对CVS历史很重要,特别是向非信徒证明迁移没有破坏他们的代码,之前已经破坏了！).
> …一些细节留待进一步讨论……

对于好奇的人来说,本月我们接近200个带注释的实体:-).典型的100字段实体需要大约30分钟的迁移工作.剩下的600个实体只剩下300个小时来完成这个cut’n粘贴！