DataNucleus是Kodo JDO的后继​​者吗？

Question

我继承了15年以上的JEE应用程序，该应用程序使用了长期以来不受支持的称为Kodo by Solarmetric (v4)的持久层。然后，BEA收购了Solarmetrics，甲骨文随后收购了BEA。自从停止对持久层的支持以来，我一直依靠15年以上的技术来为整个持久层提供动力。 应用。

我希望更改持久性实现。根据我的推断，Kodo是基于JDO规范的（但不能完全确定是哪个版本）。

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

相反，我希望了解是否可以使用最新的JDO实现（例如DataNucleus）更轻松地升级/替换。

在将这种旧技术升级到最新技术方面，任何人都没有任何经验/成功案例。 DataNucleus是否向后兼容像Kodo一样古老且不受支持的东西？自2005年以来，JDO规范是否发生了足够的变化，以至于基于2005的实现需要大量重写才能支持2018年的实现？

Answer 1

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曾经支持的任何东西都先进（在Oracle放弃使用它的人之前，他们做了JDO 2.0）。人们已经成功地升级了JDO应用程序，以使用其他JDO提供程序提供的DataNucleus，但是该问题的答案取决于您是否使用了Kodo的供应商扩展。当然，DataNucleus也是开源的（与Kodo不同），因此可以保护您免遭公司的赎金，如果有问题，可以进行修复。

自JDO 2.0（使用的方式）以来，JDO有了显着扩展，增加了注释，键入安全查询，许多其他查询方法以及其他功能。我记得所有版本的JDO都向后兼容。查看Apache JDO website和DataNucleus docs，看看JDO中发生了什么变化。

Answer 2

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