DataNucleus 是 Kodo JDO 的继任者吗?

Is DataNucleus the successor to Kodo JDO?

我继承了 15 年以上的 JEE 应用程序,它使用了一个长期以来不受支持的持久层,称为 Kodo by Solarmetric (v4)。 Solarmetrics 随后被 BEA 收购,BEA 随后被 Oracle 收购。对该持久层的支持早已停止,我依靠 15 年以上的技术来支持整个 申请。

我希望更改持久性实现。据我推断,Kodo 基于 JDO 规范(但不完全确定是哪个版本)。

用 Hibernate 或纯 JPA 解决方案替换该技术将是一场噩梦 - 应用程序中的太多逻辑都依赖于 JDO 实体 ID。

相反,我想看看是否可以更轻松地 upgrade/replace 使用更新的 JDO 实现,例如 DataNucleus。

有没有人有任何 experience/success 将这种旧技术升级为更新技术的故事。 DataNucleus 是否向后兼容像 Kodo 这样古老且不受支持的东西?自 2005 年以来,JDO 规范是否发生了足够大的变化,以至于基于 2005 年的实现需要大量重写才能支持 2018 年的实现?

DataNucleus 是 JDO 的独立(开源)实现(就此而言也是 JPA)。它以 TJDO 开始,然后成为 JPOX(并成为 JDO 2.0 的参考实现),然后在 2008 年更名为 DataNucleus。它仍然是 JDO(JDO2.0、2.1、2.2、3.0、3.1、和 3.2).

它目前实现了 JDO 3.2,它比 Kodo 支持的任何东西都先进得多(他们开发了 JDO 2.0,在 Oracle 放弃它来打击任何使用它的人之前)。人们已成功升级 JDO 应用程序以使用来自其他 JDO 提供商的 DataNucleus,但该问题的答案取决于您是否使用了 Kodo 的供应商扩展。当然,DataNucleus 也是开源的(与 Kodo 不同),因此您不会被公司勒索赎金,如果您遇到问题,可以贡献修复程序。

自 JDO 2.0(您使用的)以来,JDO 得到了显着扩展,添加了注释、类型安全查询、更多的查询方法以及其他功能。根据我的记忆,JDO 的所有版本都旨在向后兼容。去看看 Apache JDO website and the DataNucleus docs 看看 JDO 有什么变化。

我没有使用 Kodo,但使用了 JDO 和 DataNucleus 的其他实现。我只能说,我认为可以将代码移植到 DataNucleus。通常它应该是向后兼容的,改变的主要是配置而不是代码。我强烈建议不要尝试将它转移到其他标准,因为 JDO 比 JPA 或 Hibernate 更广泛和更有弹性 - 因此它不仅更容易移植,而且更容易进一步开发。