Google App Engine의 자바 용 JDO와 JPA

Google App Engine의 자바 용 JDO와 JPA

---

Struts2로 Google App Engine에서 프로젝트를 개발하고 싶습니다. 데이터베이스의 경우 JPA와 JDO의 두 가지 옵션이 있습니다. 제발 제게 제안 해 주 시겠어요? 둘 다 저에게 새롭고 배워야합니다. 그래서 나는 당신의 대답 후에 하나에 집중할 것입니다.

감사.

---

JPA는 지속성에 대한 Sun의 표준이고 JDO는 IMHO 죽어 가고 있습니다 (실제로는 죽었지 만 여전히 움직이고 있습니다). 즉, JPA는 장기적으로 더 나은 투자 인 것 같습니다. 그래서 둘 다 나에게 처음이라면 JPA를 선택했을 것입니다.

---

GAE / J Google 그룹에는 이에 대한 여러 게시물이 있습니다. 나는 거기를 검색하고 사람들의 의견을 볼 것입니다. 위에 표현 된 의견과는 매우 다른 메시지를 받게됩니다. 또한 BigTable이 RDBMS가 아니라는 사실에 주목하십시오. 작업에 적합한 도구 사용

---

DataNucleus가 직접 JPA와 JDO를 비교 한 내용은 다음과 같습니다.- http ://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html 눈을 뜨게하는 사람.

---

저는 JDO의 행복한 사용자입니다. 좋은 일을 계속하십시오.

---

JDO가 죽었다고 주장하는 사람들은 장점이 없습니다. Pro EJB 3 Java Persistence API 책에서 읽은 내용은 다음과 같습니다. "곧 Sun은 JDO가 사양 유지 관리 모드로 축소되고 Java Persistence API가 JDO 및 다른 지속성 공급 업체에서 가져와 단일 지원이 될 것이라고 발표했습니다. 앞으로 표준. ". 저자 Mike Keith는 EJB3의 공동 사양 리더입니다. 물론 그는 JPA의 열렬한 지지자이지만 거짓말을 할만큼 편견이있는 것 같지는 않다.

이 책이 출판되었을 때 JDO가 JPA보다 고급 기술 기능을 가지고 있음에도 불구하고 대부분의 주요 공급 업체가 JDO가 아닌 JPA를 기반으로 통합 된 것은 사실입니다. IBM / Oracle과 같은 EE 세계의 대기업도 대형 RDBMS 공급 업체이기 때문에 놀라운 일이 아닙니다. 더 많은 고객이 프로젝트에서 비 RDMBS보다 RDMBS를 사용하고 있습니다. JDO는 GAE가 큰 도움을 줄 때까지 죽어 가고있었습니다. GAE 데이터 저장소는 관계형 데이터베이스가 아니기 때문에 의미가 있습니다. 집계 쿼리, 조인 쿼리, 소유 된 다 대다 관계와 같은 일부 JPA 기능은 bigtable에서 작동하지 않습니다. BTW, GAE는 JDO 2.3을 지원하고 JPA 1.0 만 지원합니다. GAE가 타겟 클라우드 플랫폼이라면 JDO를 추천하겠습니다.

---

기록을 위해 Google App Engine (GAE)이므로 Oracle / Sun 규칙이 아닌 Google 규칙을 사용합니다.

그 아래에서 JPA는 GAE에 적합하지 않고 불안정하며 예상대로 작동하지 않습니다. Google은 지원할 의사가 없지만 최소한의 지원을 제공합니다.

그리고 다른 부분에서 JDO는 GAE에서 상당히 안정적이며 Google에서 (일부 확장) 잘 문서화되어 있습니다.

그러나 Google은 이들 중 어느 것도 권장하지 않습니다.

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

저수준 API는 최고의 성능을 제공하며 GAE는 성능에 관한 것입니다.

http://gaejava.appspot.com/

예를 들어 엔티티 10 개를 추가합니다.

파이썬 : 68ms

JDO : 378ms

자바 네이티브 : 30ms

---

JDO와 JPA의 경쟁에서 나는 데이터 핵 포스터에만 동의 할 수 있습니다.

우선, 가장 중요한 것은 datanucleus의 포스터가 그들이 무엇을하고 있는지 알고 있다는 것입니다. 그들은 결국 영구 라이브러리를 개발하고 있으며 관계형 이외의 데이터 모델 (예 : Big Table)에 익숙합니다. 나는 id가 hibernate에 대한 개발자가 여기에 있었다고 확신한다. 그는 "우리의 핵심 라이브러리를 구축 할 때 우리의 모든 가정은 관계형 모델과 밀접하게 결합되어 있으며, hibernate는 GAE에 최적화되어 있지 않다"고 말할 것이다.

둘째, JPA는 의심 할 여지없이보다 광범위하게 사용되며 공식 Java EE 스택의 일부가되는 데 도움이되지만 반드시 더 나은 것은 아닙니다. 사실 JDO는 JPA보다 더 높은 수준의 추상화에 해당합니다. JPA는 RDBMS 데이터 모델과 밀접하게 연결되어 있습니다.

프로그래밍 관점에서 볼 때 JDO API를 사용하는 것이 훨씬 더 나은 옵션입니다. 개념적으로 타협하는 것이 훨씬 적기 때문입니다. 사용하는 제공자가 기본 데이터베이스를 지원하는 경우 이론적으로 원하는 데이터 모델로 전환 할 수 있습니다. (실제로는 GAE의 개체에 기본 키를 설정하고 특정 데이터베이스 공급자 (예 : google)에 연결하게되므로 이러한 높은 수준의 투명성을 거의 달성하지 못합니다.) 그래도 마이그레이션하는 것이 더 쉬울 것입니다.

셋째, Hibernate, Eclipse Link 및 GAE와 함께 스프링을 사용할 수 있습니다. Google은 애플리케이션을 빌드하는 데 사용되는 프레임 워크를 사용할 수 있도록 많은 노력을 기울인 것 같습니다. 그러나 사람들이 마치 RDBMS에서 실행되는 것처럼 GAE 애플리케이션을 빌드 할 때 깨닫는 것은 속도가 느리다는 것입니다. GAE의 봄은 느립니다. 이 주제에 대한 Google IO 비디오를 검색하여 사실인지 확인할 수 있습니다.

또한 표준을 준수하는 것은 원칙적으로 박수를 보냅니다. 반면에 JPA는 Java EE 스택의 일부이기 때문에 사람들은 때때로 옵션 개념을 잃게됩니다. 원하는 경우 Java Server Faces도 Java EE 스택의 일부임을 인식하십시오. 그리고 웹 GUI 개발을위한 믿을 수 없을 정도로 깔끔한 솔루션입니다. 그러나 결국, 내가 그렇게 말할 수 있다면 더 똑똑한 사람들이이 표준에서 벗어나 대신 GWT를 사용하는 이유는 무엇입니까?

이 모든 과정에서 JPA에 대한 매우 중요한 일이 하나 있음을 확인해야합니다. 이것이 Guice와 JPA에 대한 편리한 지원입니다. Google은이 시점에서 평소처럼 똑똑하지 않았으며 현재로서는 JDO를 지원하지 않는 것에 만족합니다. 나는 여전히 그들이 그것을 감당할 수 있다고 생각하고 결국 Guice는 JDO도 삼킬 것입니다.

---

JDO로 이동하십시오. 경험이 없어도 습득하기 어렵지 않고 새로운 기술을 습득 할 수 있습니다!

---

JDO이 글을 쓰는 시점에서 사용하는 것이 끔찍하다고 생각 하는 것은 유일한 구현 공급 업체 Datanucleus이며 그 단점은 다음과 같은 수많은 문제로 이어지는 경쟁이 없다는 것입니다.

1. 다음과 같은 일부 측면에 대한 자세한 문서는 extensions
2. 일반적으로 작성자로부터 (로그를 확인 했습니까? 로그를 확인한 이유가있을 수 있음)과 같은 비꼬는 응답과 이와 같은 성가신 응답을받습니다.
3. 도움이되는 시간 내에 질문에 대한 답변을 얻지 못합니다. 때로는 7 일 이내에 답변을 받으면 여기에서도 스스로 운이 좋다고 생각해야합니다. StackOverflow

나는 항상 누군가가 JDO직접 사양을 구현하기를 바라고 있습니다. 그러면 작성자가 상업적 지원에만 관심이 있다고 말하는 것이 아니라 커뮤니티에 더 많은 무료 관심을 제공하고 지원 비용을 항상 Datanucleus신경 쓰지 않을 것입니다. , 그러나 나는 단지 말하는 것입니다.

I personally consider Datanucleus authors has no obligation whatsoever to Datanucleus itself nor it's community. They can drop the whole project at anytime and no one can judge them for it, it's their effort and their own property. But you should know what you are getting into. You see, when one of us developers look for a framework to use, you cannot punish or command the framework's author, but on the other hand, you need your work done ! If you had time to write that framework, why would you look for one in the first place ?!

On the other hand, JDO itself has some complications like objects life cycle and stuff which isn't very intuitive and common (I think).

Edit: Now I know also JPA enforces the object life cycle mechanism, so it looks like its inevitable to deal with persisted entities life cycle states if you wish to use a standard ORM API (i.e. JPA or JDO)

What I like most about JDO is the ability to work with ANY database management system without considerable effort.

---

GAE/J is slated to add MYSQL before the end of the year.

---

JPA is the way to go as it seems to be pushed as a standardized API and has recently got momentum in EJB3.0.. JDO seems to have lost the steam.

---

Neither!

Use Objectify, because is cheaper (use less resources) and is faster. FYI: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify is a Java data access API specifically designed for the Google App Engine datastore. It occupies a "middle ground"; easier to use and more transparent than JDO or JPA, but significantly more convenient than the Low-Level API. Objectify is designed to make novices immediately productive yet also expose the full power of the GAE datastore.

Objectify lets you persist, retrieve, delete, and query your own typed objects.

@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);

참고URL : https://stackoverflow.com/questions/1418219/jdo-vs-jpa-for-java-on-google-app-engine