Google App Engine上的JDO vs JPA for Java

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

谢谢.

1> DataNucleus..：

---

GAE/J谷歌小组有几个关于这件事的帖子.我会在那里搜索并查看人们的意见.您将收到与上述观点截然不同的信息.还要关注BigTable不是RDBMS的事实.使用正确的工具完成工作

---

JPA对非RDBMS数据存储的支持涉及对API和查询语言的妥协.许多东西不适合所以不支持,因为它们是特定于RDBMS的(例如JPQL的重要部分,或许多JPA注释等).因此,您无法跨数据存储区实现完全可移植性,因此在BigTable上使用JPA作为RDBMS存储所使用的直接副本的任何参数都是错误的.

---

我从来没有说过你可以使用完整的JPA API,但对我来说,这不会阻止你重复使用你的JPA知识,所以这不是不使用JPA的正当理由.而BTW,数据存储中的可移植性**在现实生活中不会发生**.

---

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

---

无论我说什么,你都不会同意所以讨论是毫无意义的,也不是大胆的类型.是的,数据存储的可移植性确实发生了,因为我有客户这样做.一如既往,人们应该根据他们的项目需求自行决定事情,这就是我们在DataNucleus文档中所说的.--Andy(DataNucleus)

---

为什么Google App Engine使用datanucleus-appengine插件(引用http://www.datanucleus.org/products/accessplatform/appengine/support.html)为其BigTable数据存储区支持JPA,如果这是完全错误的话？你能详细说明一下吗？

---

Andy,您能举例说明JPA没有的BigTable功能吗？即使是JPA可能的功能的例子,但是笨拙地工作......

2> Pascal Thive..：

---

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一起使用？谢谢.

---

伙计们,如果谷歌选择了它,那么它就不会死亡.他们知道他们做了什么.顺便说一句,恭喜@DataNucleus.我见过他们选择你的实施.

---

这是一个糟糕的答案.JPA特定于rdbms.因此,它不能用于我们近年来看到的替代数据存储(所谓的NoSQL)的大量增加.至少没有做出丑陋的妥协.因此,请不要将"JPA is daed"标记为正确答案

---

永远不应该根据受欢迎程度选择选项.整个GAE平台基于大桌面,这就是JDO的用途!

3> Vinod..：

---

刚刚看到DataNucleus自己对JPA和JDO的比较: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html 令人大开眼界.

---

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

---

这个Datanucleus的宣言似乎非常亲JDO.他们所有的陈述似乎都批评JPA和JDO的防御,但我发现使用JPA比使用JDO更快乐.

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/Oracle这样的EE世界中的大型企业也是大型RDBMS供应商.在他们的项目中,更多的客户使用RDMBS而不是非RDMBS.JDO一直在奄奄一息,直到GAE给予了很大的推动.这是有道理的,因为GAE数据存储不是关系数据库.某些JPA功能不适用于bigtable,例如聚合查询,加入查询,拥有多对多关系.BTW,GAE支持JDO 2.3,同时仅支持JPA 1.0.如果GAE是您的目标云平台,我会推荐JDO.

6> magallanes..：

---

据记录,它是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:68ms

JDO:378ms

Java Native:30ms

7> 99Sono..：

---

在JDO与JPA之间的竞赛中,我只能同意数据核心海报.

首先,也是最重要的是,数据核的海报知道他们在做什么.毕竟他们正在开发一个持久性库,并熟悉除关系之外的数据模型,例如Big Table.我相信,ID为休眠开发商在这里,他会说:"我们所有的假设,建立我们的核心库时紧耦合关系模型,Hibernate是不是GAE优化".

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

从编程的角度来看,使用JDO API是一个更好的选择,因为从概念上来说,您的妥协要少得多.如果您使用的提供程序支持底层数据库,您可以在理论上切换到您想要的任何数据模型.(在实践中你很少达到transparancy这么高的水平,因为你会发现自己GAE的对象上设置主键,您将自己绑到特定的数据库提供商,如谷歌).尽管如此,迁移仍然会更容易.

第三,你可以使用Hibernate,Eclipse Link,甚至可以使用GAE.Google似乎已经付出了巨大努力,允许您使用用于构建应用程序的框架.但人们在构建GAE应用程序时意识到他们在RDBMS上运行的原因是它们很慢.GAE上的春天很慢.您可以针对此主题谷歌Google IO视频,看看它是否属实.

此外,坚持标准是一件很明智的事情,原则上我鼓掌.另一方面,JPA是Java EE堆栈的一部分,人们有时会失去他们的选择概念.如果愿意,请实现Java Server Faces也是Java EE堆栈的一部分.对于Web GUI开发来说,这是一个令人难以置信的整洁解决方案.但最后,为什么人们,如果我可以这么说,那些更聪明的人会偏离这个标准并改用GWT？

在所有这一切中,我必须认为JPA有一个非常重要的事情.这就是Guice及其对JPA的便捷支持.似乎谷歌在这一点上并不像往常一样聪明并且满足,因为现在不支持JDO.我仍然认为他们可以负担得起,最终Guice也将吞没JDO,......或许不会.

8> corydoras..：

---

去JDO.即使你没有经验,也不难接受,你将拥有一项新技能!

9> Muhammad Gel..：

---

我认为JDO在撰写本文时使用的可怕之处在于,唯一的实施供应商是Datanucleus,缺点是缺乏竞争导致许多问题,如:

关于某些方面的非常详细的文档 extensions

你通常会得到作者的讽刺反应(你有没有检查过日志？可能是有理由让他们有这些)和恼人的回应

在有用的时间内你没有得到你的问题的答案,有时如果你在不到7天的时间内得到答案,你应该认为自己很幸运,即使在这里 StackOverflow

我一直希望有人自己开始实施JDO规范,然后他们可能会提供更多的东西,希望更多的自由关注社区,而不是总是为获得支持而烦恼,而不是说Datanucleus作者只关心商业支持,但我只是说.

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

另一方面,JDO它本身有一些复杂的问题,比如物体生命周期和不太直观和常见的东西(我认为).

编辑:现在我知道也JPA强制执行对象生命周期机制,因此如果您希望使用标准ORM API(即JPA或JDO),它看起来像处理持久化实体生命周期状态是不可避免的

我最喜欢的JDO是能够毫不费力地使用任何数据库管理系统.