Solarmetric的Abe White对我对TSS上JDO的批评进行了回应。实际上，我对进行漫长的争论并不感兴趣，但既然我的第一篇帖子中确实存在错误，我必须承认这一点。
首先，Abe展示了一个看起来在HQL和JDOQL中表面上相似的简单查询。我不确定这到底要证明什么，但我不想就这一点进行长时间的争论。我鼓励任何感兴趣的人自己比较这两种查询语言。我坚信，ORM的查询语言应该看起来像SQL。（与HQL和EJBQL不同，JDOQL并不是专门针对ORM的，这也解释了一些不同的观点。）我想明确指出，对我个人来说，真正的问题是查询语言。
Abe指出，我在JDO解附（detachment）中未检索关联的语义上犯了错误。我接受了纠正。从JDO1规范，以及与JDO EG成员的早期对话中，我理解JDO团队坚持认为增强类不需要在客户端
上，这意味着客户端无法对序列化实例进行拦截。显然，他们已经改变了主意，取消了这一要求。我想这应该是合理的。这可能意味着在类加载时进行增强会有困难，但我不确定这一点，并且我确实接受在构建时增强作为支持解附/重新附加的合理方法。
有人建议我对字段拦截的其他反对意见可能是错误的，但我想我在这些方面是正确的。我认为如果你仔细考虑多态关联和解附如何使情况复杂化，你会看到这一点。（记住，我们无法决定关联实例的具体子类，除非我们击中其数据库表或表。）
最后，Abe认为JDO实际上只具有与Hibernate完全相同的类型
的身份和实例状态。我同意——这正是问题所在！让我们来看看身份。实际上只有一种有趣的身份：持久身份。唯一应该变化的是身份值（主键值）的分配方式。但JDO对数据存储
身份（由持久化层生成的代理键）和应用
身份（由应用程序分配的自然键）有不同的表示。JDO2添加了简单
身份来掩盖这个问题，进一步复杂了局面。
好吧，没有时间再说了，我得赶飞机了。当然，每个人都认为自己的技术是最好的，而且批评它的人都是错误的/愚蠢的/散播恐惧等。我根本不期望关于这个问题的辩论会产生任何明确的赢家（而不是声誉受损）。我也有错误，JDO的人也有错误，每个人都会有错误。我更喜欢屈服于达尔文主义，看看实际项目中实际采用的解决方案。
