Google App Engine 上的 JDO 与 JPA for Java

Posted 2023-02-24

【中文标题】Google App Engine 上的 JDO 与 JPA for Java

【英文标题】：JDO vs JPA for Java on Google App Engine

【发布时间】：2010-11-27 22:35:25

【问题描述】：

我想使用 Struts2 在 Google App Engine 上开发我的项目。对于数据库，我有两个选项 JPA 和 JDO。你们会建议我吗？两者对我来说都是新的，我需要学习它们。所以我会在你回复后专注于一个。

谢谢。

【参考方案1】：

GAE/J google 小组有几篇关于这件事的帖子。我会在那里搜索并查看人们的意见。你会得到与上述观点截然不同的信息。还要关注 BigTable 不是 RDBMS 的事实。为工作使用正确的工具

【讨论】：

如果完全错误，为什么 Google App Engine 使用 datanucleus-appengine 插件（引用 datanucleus.org/products/accessplatform/appengine/support.html）为其 BigTable 数据存储支持 JPA？你能详细说明一下吗？

JPA 对非 RDBMS 数据存储的支持涉及对 API 和查询语言的妥协。许多东西不适合因此不受支持，因为它们是特定于 RDBMS 的（例如 JPQL 的重要部分，或许多 JPA 注释等）。因此，您不能在数据存储之间拥有完全的可移植性，因此任何关于在 BigTable 上使用 JPA 作为您用于 RDBMS 存储的直接副本的任何论点都是错误的。

另一方面，对于 JDO，查询语言 (JDOQL) 没有特定于 RDBMS 的组件，并且元数据在整体上是数据库中立的，而特定于 RDBMS 的组件完全分离。因此，您确实具有数据存储之间的可移植性。 JDO API 允许在需要时为每个数据存储使用本机查询语言。

我从未说过您可以使用完整的 JPA API，但对我来说，这不会阻止您重用您的 JPA 知识，因此这不是不使用 JPA 的正当理由。顺便说一句，跨数据存储的可移植性在现实生活中不会发生。

无论我说什么你都不会同意，所以讨论毫无意义，也不需要粗体字。是的，跨数据存储的可移植性确实发生了，因为我有客户这样做。与往常一样，人们应该根据他们的项目需求自己决定事情，这就是我们在 DataNucleus 文档中所说的。 --Andy (DataNucleus)

【参考方案2】：

JPA 是 Sun 的持久性标准，JDO 恕我直言正在消亡（实际上，它已经消亡但仍在发展）。换句话说，从长远来看，JPA 似乎是一项更好的投资。所以我想如果两者对我来说都是新手，我会选择 JPA。

【讨论】：

JDO 并没有消亡，而是针对不同的受众。请检查你的事实。 JDO 有 JDO 2.1、JDO 2.2 和现在的 JDO 2.3。 JDO 独立于数据存储。 JPA 仅针对 RDBMS。事实

好吧，无论有多少版本，我认为我们不能说采用 JDO 是成功的。睁大你的眼睛，JDO 可能有数十亿个版本，反正没有人在使用它（请不要告诉我 JDO 会因为 GAE 而重生）。那么，如果 JPA 仅针对 RDBMS，请解释为什么我们可以将此 API 与 Google 的 BigTable 一起使用？谢谢。

伙计们，如果 Google 选择了它，那么它不会死。他们知道自己在做什么。顺便说一句，恭喜@DataNucleus。我看到他们选择了你的实现。

这是一个糟糕的答案。 JPA 是特定于 rdbms 的。因此，它不能与我们近年来看到的大量替代数据存储（所谓的 NoSQL）一起使用。至少没有做出丑陋的妥协。所以，请不要将“JPA is daed”标记为正确答案

永远不要根据受欢迎程度来选择选项。整个 GAE 平台是基于大表的，这就是 JDO 的用途！

【参考方案3】：

刚刚看到 DataNucleus 自己对 JPA 和 JDO 进行了比较：- http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html 大开眼界。

【讨论】：

这个 Datanucleus 的宣言似乎非常支持 JDO。他们的所有言论似乎都批评 JPA 并捍卫 JDO，但我发现使用 JPA 比使用 JDO 更快乐。

DataNucleus 同时支持 JDO 和 JPA，我们实际上只是在 DN 2.0 中包含了大部分 JPA2。与所有其他持久性解决方案不同，我们同时推广两者，并让用户选择。如果您认为 JDO 或 JPA 的任何报道中存在事实错误，我们欢迎您提供意见。如果您代表您参与政治议程，那么最好将您的感受隐藏在自己身上

【参考方案4】：

我是 JDO 的快乐用户。继续努力，伙计们。

【讨论】：

我是一个快乐的 JDO 用户：一旦我习惯了它就非常适合我。此外，通过 JDO，我可以选择离开 GAE/J 和 Google BigTable，而无需完全重新设计我的持久数据交换。

【参考方案5】：

声称 JDO 已死的人并非没有根据。这是我在 Pro EJB 3 Java Persistence API 一书中读到的内容：“不久之后，Sun 宣布 JDO 将简化为规范维护模式，Java Persistence API 将从 JDO 和其他持久性供应商那里汲取灵感，成为唯一受支持的标准向前发展。”。作者 Mike Keith 是 EJB3 的共同规范负责人。当然，他是 JPA 的大力支持者，但我怀疑他是否有足够的偏见撒谎。

确实，当本书出版时，大多数主要供应商都联合支持 JPA 而不是 JDO，尽管 JDO 确实具有比 JPA 更先进的技术特性。这并不奇怪，因为 EE 领域的大玩家，如 IBM/Oracle 也是大型 RDBMS 供应商。与非 RDMBS 相比，在他们的项目中使用 RDMBS 的客户更多。在 GAE 大力推动 JDO 之前，JDO 一直在消亡。这是有道理的，因为 GAE 数据存储不是关系数据库。一些 JPA 功能不适用于 bigtable，例如聚合查询、联接查询、拥有的多对多关系。顺便说一句，GAE 支持 JDO 2.3，而仅支持 JPA 1.0。如果 GAE 是您的目标云平台，我会推荐 JDO。

【参考方案6】：

为了记录，它是 Google App Engine (GAE)，所以我们使用 Google 规则而不是 Oracle/Sun 规则。

在它下面，JPA 不适合 GAE，它不稳定，不能按预期工作。谷歌都不愿意支持它，但最低限度。

在其他方面，JDO 在 GAE 中相当稳定，并且（在某种程度上）被 Google 详细记录。

但是，Google 不推荐其中任何一个。

http://code.google.com/appengine/docs/java/datastore/overview.html

低级 API 将提供最佳性能，而 GAE 就是关于性能的。

http://gaejava.appspot.com/

例如添加10个实体

Python :68 毫秒

JDO :378 毫秒

Java 原生：30 毫秒

【讨论】：

这不是我在运行您的测试时得到的结果。

【参考方案7】：

在 JDO 与 JPA 之间的比赛中，我只能同意 datanucleus 海报。

首先，也是最重要的，datanucleus 的发布者知道他们在做什么。毕竟，他们正在开发一个持久库，并且熟悉关系以外的数据模型，例如大桌子。我敢肯定，这里有一个 hibernate 开发人员，他会说：“我们在构建核心库时的所有假设都与关系模型紧密耦合，hibernate 没有针对 GAE 进行优化”。

其次，毫无疑问，JPA 的使用范围更广，成为官方 Java EE 堆栈的一部分会有所帮助，但这并不一定意味着它会更好。 事实上，如果您阅读过 JDO，它对应于比 JPA 更高级别的抽象。 JPA 与 RDBMS 数据模型紧密耦合。

从编程的角度来看，使用 JDO API 是一个更好的选择，因为您在概念上的妥协要少得多。理论上，您可以切换到您想要的任何数据模型，前提是您使用的提供程序支持底层数据库。 （实际上，您很少能达到如此高的透明度，因为您会发现自己在 GAE 的对象上设置了主键，并且您会将自己绑定到特定的数据库提供商，例如 google）。不过迁移起来还是比较容易的。

第三，您可以使用 Hibernate、Eclipse Link，甚至 Spring 与 GAE。谷歌似乎做了很大的努力来允许你使用你用来构建应用程序的框架。但是当人们像在 RDBMS 上运行一样构建 GAE 应用程序时，他们意识到它们很慢。 GAE 上的春天很慢。您可以在 Google IO 上搜索有关此主题的视频，看看是否属实。

此外，遵守标准是一件明智的事情，原则上我对此表示赞赏。另一方面，作为 Java EE 堆栈的一部分的 JPA 有时会让人们失去他们的选项概念。 如果您愿意，请意识到 Java Server Faces 也是 Java EE 堆栈的一部分。对于 Web GUI 开发来说，它是一个令人难以置信的整洁解决方案。但最后，为什么人们，如果我可以这么说的话，更聪明的人，会偏离这个标准而使用 GWT？

在所有这些中，我必须说明 JPA 有一件非常重要的事情。这就是 Guice 及其对 JPA 的便捷支持。似乎谷歌在这一点上不像往常那样聪明并且满足，目前不支持 JDO。我仍然认为他们负担得起，最终 Guice 也会吞并 JDO，……或者可能不会。

【参考方案8】：

去 JDO。就算没有经验，上手也不难，一身新技能！

【参考方案9】：

在撰写本文时，我认为使用 JDO 的糟糕之处在于，唯一的实现供应商是 Datanucleus，其缺点是缺乏竞争，这会导致许多问题，例如：

关于 extensions 等某些方面的不是很详细的文档 您通常会从作者那里得到讽刺性的回应，例如（您检查过日志吗？可能有它们的原因）以及诸如此类的烦人的回应 您没有在很长一段时间内得到问题的答案，有时如果您在不到 7 天的时间内得到答案，您应该认为自己很幸运，即使在 *** 上也是如此

我一直希望有人自己开始实施JDO 规范，可能到那时他们会提供更多的东西，并希望更多地免费关注社区，而不是总是为成为付费支持，并不是说Datanucleus作者只关心商业支持，但我只是说。

我个人认为Datanucleus 作者对Datanucleus 本身及其社区没有任何义务。他们可以随时放弃整个项目，没有人可以评判他们，这是他们的努力和他们自己的财产。但是你应该知道你在做什么。你看，当我们中的一个开发人员寻找要使用的框架时，你不能惩罚或命令框架的作者，但另一方面，你需要完成你的工作！如果您有时间编写该框架，您为什么要首先寻找一个？！

另一方面，JDO 本身也有一些复杂性，比如对象生命周期和不太直观和常见的东西（我认为）。

编辑：现在我也知道 JPA 强制执行对象生命周期机制，因此如果您希望使用标准 ORM API（即 JPA 或 @987654332 @)

我最喜欢JDO 的地方在于能够轻松使用任何数据库管理系统。

【讨论】：

您对几乎所有观察结果都是正确的。对于一些复杂的持久对象来说，ORM 是一件令人头疼的事情（字面意思是几个月的调试！）。目前我坚持使用 DN 2.1，因为属性已更改，并且我的代码不适用于较新的版本。也就是说，在我看来，DN 和 JDO 是可行的方法。

【参考方案10】：

GAE/J 计划在年底前添加 mysql。

【讨论】：

你有这个来源吗？

投了反对票，因为我认为这不是真的，在网上找不到任何支持它的信息，并且帖子没有提供任何证据。

路线图提到功能齐全的 SQL 数据库正在开发中code.google.com/appengine/business/roadmap.html

有趣但现在 (31-08-2011) 我们发现这根本不是真的。

不正确？ Google 的 App Engine SQL 预览版（测试版）网址很长，所以我将其缩短了 goo.gl/AhsxX（认为需要解释一下，以防万一您不是信徒）。

【参考方案11】：

JPA 是一种可行的方法，因为它似乎被推为标准化 API，并且最近在 EJB3.0 中获得了动力。JDO 似乎失去了动力。

【参考方案12】：

没有！

使用 Objectify，因为它更便宜（使用更少的资源）并且速度更快。 仅供参考：http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify 是一个 Java 数据访问 API，专为 谷歌应用引擎数据存储。它占据了“中间地带”；更容易 使用并且比 JDO 或 JPA 更透明，但明显更多 比低级 API 更方便。 Objectify 旨在使 新手立即富有成效，同时也暴露了 GAE 数据存储。

Objectify 让您可以持久化、检索、删除和查询您自己的类型化对象。

@Entity
class Car 
    @Id String vin; // Can be Long, long, or String
    String color;


ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);

【讨论】：

这仅适用于数据存储吗？云sql呢？

而缺点是您与供应商紧密相连。并不总是一个问题，但 JDO 的全部意义在于避免这种情况。 （作为一个可能会将其用于小型服务的人）。