相关信息

Hibernate 3.0 是世界上最为复杂的对象/关系/XML 映射（ORXM）解决方案。Hibernate3 使 Java 应用程序与持久数据交互变得比以往任何时候都更容易，允许对实体数据的内存表示与关系模式之间进行单一的定义转换，即使在非常复杂的遗留模式或历史数据模式以及具有可见性规则的数据中也是如此。Hibernate3 还提供了最全面的对象/关系查询功能，包括三个功能齐全的查询工具：Hibernate 查询语言、新增强的 Hibernate 条件查询 API 以及对数据库原生 SQL 语句查询的支持。

塞德里克抢在我前面，但如果你错过了他的公告，EJB 3.0 第二次早期草案已经可用。对我来说最有趣的新内容是

我们刚刚发布了 Hibernate 3.0 测试版 1。自从四个月前 alpha 版发布以来，我无暇列举所有许多变化，更不用说 Hibernate3 中所有新内容，Hibernate3 已经开发了一年多。

类型——不是性别或种族——的歧视是我们从 SQL 查询结果集中读取一行，并确定应该实例化什么 Java 类来保存该行数据时所做的事情。类型歧视是任何支持多态查询或关联的 ORM 解决方案或手写持久层所必需的。

9月20日至22日在墨尔本，我们将首次提供我们的三天Hibernate课程。课程经过大量修订和扩展，包括Hibernate3中即将推出的一些新内容的预览以及Hibernate内部的概述（如果需要调试Hibernate应用程序，这将非常有用）。如果你们快的话，还有空余名额！这是我在未来一段时间内在澳大利亚举办的最后一次培训，因为我在接下来的六个月左右的时间里将不会在这个国家停留。如果您需要更多信息，请发送电子邮件至training@jboss.com。（我们还有即将在巴黎举行的11月3日至5日的课程。）

我必须在这篇文章中先声明，我们对Java是处理大量数据的合适平台这一观点持怀疑态度。进一步说，ORM可能也不是进行批量处理特别合适的方法。我们认为大多数数据库在这一领域提供了优秀的解决方案：存储过程支持和各种导入导出工具。正因为如此，我们一直未能正确地向人们解释如何在Java中确实需要这样做时使用Hibernate进行批量处理。在某个时刻，我们必须放下我们的骄傲，接受很多人实际上正在这样做，并确保他们正在以正确的方式这样做。

在开源项目中与商业竞争对手合作的一个乐趣是，我们必须实现用户根本不要求，并且实际上可能不会使用的功能，只是因为这些竞争对手试图将它们无用的功能吹嘘为竞争优势。很久以前我们就意识到，如果你没有这个功能，就很难告诉人们他们不需要也不应该使用这个功能。

我们最近与一个客户合作进行了一项工作，他们有一个非常庞大的项目，并且对Hibernate生成的SQL的可追溯性表示担忧。他们的问题我想很常见：假设我在Hibernate日志中看到某些问题（比如N+1选择问题），我怎么知道是哪个业务类产生了这个问题？我在Hibernate日志中唯一能看到的是org.hibernate.SQL，第224行作为日志消息的来源！

最近围绕像iBATIS这样的简单JDBC框架有很多讨论。我个人很喜欢iBATIS的想法，用于那些不需要面向对象的领域模型，并且不涉及单个事务中的深度关联实体图的应用程序。如果你在与某种“疯狂”的遗留数据库一起工作，JDBC框架也很有意义；ORM解决方案通常假设关联以整洁的外键形式表示，并具有适当的引用完整性约束（Hibernate3比Hibernate 2.x要少）。

我在ejb3-feedback@sun.com上刚刚进行了一次有趣的讨论，由David Cherryhomes发起，我愚蠢地坚持认为某件事不可能做到，事实上，现在我想起来，我以前确实做到过，而且Hibernate的AdminApp 示例也使用了这种模式！