DataNucleus是Kodo的继承者吗？

Question

我继承了15+已有多年历史的JEE应用程序，它使用了一个称为太阳测量法(v4)的长期不受支持的持久性层。随后，太阳黑子被BEA收购，随后被甲骨文收购。对这个持久化层的支持早已停止，我依赖于15+已有多年的技术来驱动整个应用程序。

我希望更改持久性实现。从我所能推断出来的情况来看，Kodo是基于JDO规范(但并不完全确定是哪个版本)。

若要用Hibernate或纯JPA解决方案代替该技术，那将是一场噩梦--应用程序中过多的逻辑依赖于JDO实体Id。

相反，我想看看是否可以更容易地用更当前的JDO实现(如DataNucleus )来升级/替换。

有没有人有任何经验/成功的经验，将这样的老技术升级为更新的东西。DataNucleus是否向后兼容像Kodo这样老的不受支持的东西？自2005年以来，JDO规范是否发生了足够大的变化，以至于基于2005年的实现需要进行大规模重写才能支持2018实现？

Answer 1

DataNucleus是JDO的一个独立(开源)实现(而且JPA也是如此)。它以TJDO起家，然后成为JPOX (并成为JDO2.0的参考实现)，然后在2008年更名为DataNucleus。它仍然是JDO的参考实现(JDO2.0、2.1、2.2、3.0、3.1和3.2)。

它目前实现了JDO3.2，这比Kodo所支持的任何东西都要先进得多(在Oracle通过放弃JDO2.0来欺骗使用它的人之前，他们做了JDO2.0)。人们已经成功地从其他JDO提供者那里升级了JDO应用程序以使用DataNucleus，但是这个问题的答案取决于您是否使用了Kodo的供应商扩展。当然，DataNucleus也是开源的(与Kodo不同)，所以您可以受到公司的勒索保护，如果您有问题，可以提供修复。

JDO自JDO2.0(您使用的内容)以来已经有了很大的扩展，添加了注释、类型安全查询、许多更多的查询方法以及其他特性。根据我的记忆，JDO的所有版本都是向后兼容的。查看一下Apache JDO网站和DataNucleus文档，看看JDO中发生了什么变化。

Answer 2

我没有使用Kodo，但是使用了JDO和DataNucleus的其他实现。我所能说的就是，我认为可以将代码移植到DataNucleus。一般来说，它应该是向后兼容的，并且正在改变的主要是配置，而不是代码。我强烈建议不要尝试将它转移到其他标准，因为JDO比JPA或Hibernate更宽、更灵活--因此它不仅更易于移植，而且更易于进一步开发。