JDO vs JPA für Java in Google App Engine

81

Ich möchte mein Projekt in Google App Engine mit Struts2 entwickeln. Für die Datenbank habe ich zwei Optionen: JPA und JDO. Könnt ihr mir bitte einen Vorschlag machen? Beide sind neu für mich und ich muss sie lernen. Also werde ich mich nach Ihren Antworten auf eine konzentrieren.

Vielen Dank.

Tahir Akram
quelle

Antworten:

32

JPA ist Suns Standard für Persistenz, JDO stirbt IMHO (eigentlich ist es tot, aber es bewegt sich immer noch). Mit anderen Worten, JPA scheint langfristig eine bessere Investition zu sein. Ich würde mich also für JPA entscheiden, wenn beide für mich neu wären.

Pascal Thivent
quelle
52
JDO stirbt nicht und richtet sich an ein anderes Publikum. Bitte überprüfen Sie Ihre Fakten. JDO hatte JDO 2.1, JDO 2.2 und jetzt JDO 2.3. JDO ist unabhängig vom Datenspeicher. JPA richtet sich ausschließlich an RDBMS. Fakt
DataNucleus
17
Ich glaube nicht, dass wir sagen können, dass die Einführung von JDO ein Erfolg ist, egal wie viele Versionen es gibt. Öffne deine Augen, JDO könnte Milliarden von Versionen haben, niemand benutzt es sowieso (und bitte sag mir nicht, dass JDO dank GAE wiedergeboren wird). Wenn JPA ausschließlich für RDBMS bestimmt ist, erklären Sie mir, warum wir diese API mit Googles BigTable verwenden können. Vielen Dank.
Pascal Thivent
10
Leute, wenn Google es gewählt hat, dann stirbt es nicht. Sie wissen, was sie tun. Übrigens, Congrats @DataNucleus. Ich habe gesehen, dass sie Ihre Implementierung ausgewählt haben.
Santiagobasulto
6
Das ist eine schlechte Antwort. JPA ist rdbms-spezifisch. Es kann also nicht mit der massiven Verbreitung alternativer Datenspeicher (dem sogenannten NoSQL) verwendet werden, die wir in den letzten Jahren gesehen haben. Zumindest ohne hässliche Kompromisse einzugehen. Also, bitte markieren Sie nicht "JPA ist daed" als die richtige Antwort
smartnut007
2
Man sollte niemals Optionen wählen, die auf der Popularität basieren. Die gesamte GAE-Plattform basiert auf einem großen Tisch und dafür ist JDO da!
FUD
33

Die GAE / J-Google-Gruppe hat mehrere Beiträge zu genau dieser Sache. Ich würde dort suchen und mir die Meinungen der Leute ansehen. Sie erhalten eine ganz andere Botschaft als die oben geäußerten Meinungen. Konzentrieren Sie sich auch auf die Tatsache, dass BigTable kein RDBMS ist. Verwenden Sie das richtige Werkzeug für den Job

DataNucleus
quelle
3
Warum unterstützt die Google App Engine JPA für ihren BigTable-Datenspeicher mithilfe des Datanucleus-Appengine-Plugins (unter Angabe von datanucleus.org/products/accessplatform/appengine/support.html ), wenn es sich um einen Totalfehler handelt ? Können Sie das näher erläutern?
Pascal Thivent
16
Die JPA-Unterstützung für Nicht-RDBMS-Datenspeicher umfasst Kompromisse bei der API und der Abfragesprache. Viele Dinge passen nicht zusammen und werden daher nicht unterstützt, da sie RDBMS-spezifisch sind (z. B. wichtige Teile von JPQL oder viele JPA-Anmerkungen usw.). Folglich können Sie keine vollständige Portabilität über Datenspeicher hinweg haben. Daher ist jedes Argument für die Verwendung von JPA auf BigTable als direkte Kopie für das, was Sie für einen RDBMS-Speicher verwenden würden, falsch.
DataNucleus
6
Für JDO hingegen enthält die Abfragesprache (JDOQL) keine RDBMS-spezifischen Komponenten, und Metadaten sind insgesamt datenbankneutral, wobei RDBMS-spezifische Komponenten sauber getrennt sind. Folglich haben Sie Portabilität zwischen Datenspeichern. Die JDO-API ermöglicht bei Bedarf die Verwendung einer nativen Abfragesprache für jeden Datenspeicher.
DataNucleus
9
Ich habe nie gesagt, dass Sie die vollständige JPA-API verwenden können, aber für mich hindert dies Sie nicht daran, Ihr JPA-Wissen wiederzuverwenden, sodass dies kein gültiger Grund für die Nichtverwendung von JPA ist. Übrigens kommt die Portabilität über Datenspeicher im wirklichen Leben nicht vor .
Pascal Thivent
4
Was auch immer ich sage, Sie werden nicht zustimmen, so ist es sinnlos die Diskussion, noch notwendig von fettem Typ. Ja, Portabilität über Datenspeicher hinweg geschieht, da ich Clients habe, die genau das tun. Wie immer sollten die Leute die Dinge basierend auf ihren Projektanforderungen selbst entscheiden, was wir in den DataNucleus-Dokumenten sagen. - Andy (DataNucleus)
DataNucleus
24

Ich habe gerade diesen Vergleich zwischen JPA und JDO von DataNucleus selbst gesehen: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Ein Augenöffner.

Vinod
quelle
3
Das Manifest dieses Datanucleus scheint sehr pro-JDO zu sein. Alle ihre Aussagen scheinen JPA gegenüber kritisch und JDO defensiv zu sein, und dennoch finde ich die Verwendung von JPA eine glücklichere Aktivität als die Verwendung von JDO.
Seliger Geek
8
DataNucleus unterstützt sowohl JDO als auch JPA, und wir haben gerade den größten Teil von JPA2 in DN 2.0 aufgenommen. Im Gegensatz zu allen anderen Persistenzlösungen fördern wir beide und lassen die Benutzer wählen. Wenn Sie der Meinung sind, dass bei der Berichterstattung über JDO oder JPA sachliche Fehler vorliegen, würden wir uns über Ihre Eingabe freuen. Wenn Sie Teil einer politischen Agenda in Ihrem Namen sind, sollten Sie Ihre Gefühle für sich behalten
DataNucleus,
16

Ich bin ein glücklicher Benutzer von JDO. Weiter so Jungs.

Manfred
quelle
2
Ich bin ein glücklicher JDO-Benutzer: Es passt mir gut, wenn ich mich daran gewöhnt habe. Außerdem habe ich mit JDO die Möglichkeit, mich von GAE / J und Google BigTable zu entfernen, ohne meinen dauerhaften Datenaustausch komplett neu zu gestalten.
Ian Marshall
12

Menschen, die behaupten, JDO sei tot, sind nicht unbegründet. Folgendes habe ich in dem Buch Pro EJB 3 Java Persistence API gelesen: "Kurz danach gab Sun bekannt, dass JDO auf den Spezifikationswartungsmodus reduziert und die Java Persistence API sowohl von JDO als auch von den anderen Persistenzanbietern verwendet und als einziger unterstützt wird Standard für die Zukunft. ". Der Autor Mike Keith ist der Co-Spezifikationsleiter für EJB3. Natürlich ist er ein großer Unterstützer von JPA, aber ich bezweifle, dass er voreingenommen genug ist, um zu lügen.

Es ist richtig, dass bei Veröffentlichung des Buches die meisten großen Anbieter hinter JPA und nicht hinter JDO vereint waren, obwohl JDO über fortgeschrittenere technische Funktionen als JPA verfügt. Dies ist nicht überraschend, da große Unternehmen in der EE-Welt wie IBM / Oracle auch große RDBMS-Anbieter sind. In ihren Projekten verwenden mehr Kunden RDMBS als Nicht-RDMBS. JDO starb, bis GAE ihm einen großen Schub gab. Dies ist sinnvoll, da der GAE-Datenspeicher keine relationale Datenbank ist. Einige JPA-Funktionen funktionieren nicht mit Bigtables, z. B. Aggregationsabfragen, Join-Abfragen, viele-zu-viele-Beziehungen. Übrigens unterstützt GAE JDO 2.3, während nur JPA 1.0 unterstützt wird. Ich werde JDO empfehlen, wenn GAE Ihre Ziel-Cloud-Plattform ist.

Schwall
quelle
11

Für die Aufzeichnung ist es Google App Engine (GAE), also spielen wir mit den Google-Regeln, nicht mit den Oracle / Sun-Regeln.

Darunter ist JPA nicht für GAE geeignet, es ist instabil und es funktioniert nicht wie erwartet. Weder Google ist bereit, dies zu unterstützen, noch das Nötigste.

Zum anderen ist JDO in GAE ziemlich stabil und von Google (teilweise) gut dokumentiert.

Google empfiehlt jedoch keine davon.

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

Low-Level-API bietet die beste Leistung, und bei GAE dreht sich alles um Leistung.

http://gaejava.appspot.com/

Fügen Sie beispielsweise 10 Entitäten hinzu

Python: 68 ms

JDO: 378 ms

Java Native: 30 ms

Magallane
quelle
Das sind nicht die Ergebnisse, die ich bekomme, wenn ich Ihre Tests durchführe.
Code511788465541441
9

Im Rennen zwischen JDO und JPA kann ich nur den Datanucleus-Postern zustimmen.

Zuallererst und vor allem wissen die Poster von datanucleus, was sie tun. Sie entwickeln schließlich eine persistente Bibliothek und sind mit anderen Datenmodellen als dem relationalen, z. B. Big Table, vertraut. Ich bin mir sicher, dass ein Entwickler für den Ruhezustand hier wäre. Er hätte gesagt: "Alle unsere Annahmen beim Aufbau unserer Kernbibliotheken sind eng an das relationale Modell gekoppelt. Der Ruhezustand ist nicht für GAE optimiert."

Zweitens ist JPA zweifellos weit verbreitet, da es ein bisschen hilfreich ist, Teil des offiziellen Java EE-Stacks zu sein, aber das bedeutet nicht unbedingt, dass es besser ist. Tatsächlich entspricht JDO, wenn Sie darüber lesen, einer höheren Abstraktionsebene als JPA. JPA ist eng mit dem RDBMS-Datenmodell verbunden.

Vom Standpunkt der Programmierung aus ist die Verwendung der JDO-APIs eine viel bessere Option, da Sie konzeptionell viel weniger Kompromisse eingehen. Sie können theoretisch zu einem beliebigen Datenmodell wechseln, sofern der von Ihnen verwendete Anbieter die zugrunde liegende Datenbank unterstützt. (In der Praxis erreichen Sie selten ein so hohes Maß an Transparenz, da Sie Ihre Primärschlüssel für das GAE-Objekt festlegen und sich an einen bestimmten Datenbankanbieter, z. B. Google, binden.) Die Migration ist jedoch immer noch einfacher.

Drittens können Sie Hibernate, Eclipse Link und sogar Spring mit GAE verwenden. Google hat anscheinend große Anstrengungen unternommen, damit Sie die Frameworks verwenden können, auf denen Sie Ihre Anwendungen aufbauen. Die Leute erkennen jedoch, wenn sie ihre GAE-Anwendungen so erstellen, als würden sie auf RDBMS ausgeführt, dass sie langsam sind. Der Frühling auf GAE ist langsam. Sie können Google IO-Videos zu diesem Thema googeln, um festzustellen, ob es wahr ist.

Auch die Einhaltung von Standards ist eine vernünftige Sache, im Prinzip begrüße ich. Auf der anderen Seite führt JPA als Teil des Java EE-Stacks dazu, dass Benutzer manchmal ihre Vorstellung von Optionen verlieren. Wenn Sie so wollen, stellen Sie fest, dass Java Server Faces auch Teil des Java EE-Stacks ist. Und es ist eine unglaublich ordentliche Lösung für die Entwicklung von Web-GUI. Aber warum weichen Menschen, die klügeren Leute, wenn ich so sagen darf, letztendlich von diesem Standard ab und verwenden stattdessen GWT?

Bei alledem muss ich sagen, dass es für JPA eine sehr wichtige Sache gibt. Das ist Guice und seine bequeme Unterstützung für JPA. Scheint, dass Google in diesem Punkt nicht so schlau wie gewöhnlich war und zufrieden ist, weil es JDO vorerst nicht unterstützt. Ich denke immer noch, dass sie es sich leisten können, und irgendwann wird Guice auch JDO verschlingen ... oder vielleicht auch nicht.

99Sono
quelle
6

Gehen Sie JDO. Selbst wenn Sie keine Erfahrung darin haben, ist es nicht schwer zu erlernen, und Sie werden eine neue Fähigkeit unter Ihrem Gürtel haben!

Corydoras
quelle
6

Was ich JDOzum Zeitpunkt des Schreibens für schrecklich halte, ist, dass der einzige Implementierungsanbieter ist Datanucleusund die Nachteile davon der mangelnde Wettbewerb sind, der zu zahlreichen Problemen führt wie:

  1. Eine nicht sehr detaillierte Dokumentation zu einigen Aspekten wie extensions
  2. Normalerweise erhalten Sie von den Autoren sarkastische Antworten wie (Haben Sie die Protokolle überprüft? Möglicherweise gibt es einen Grund dafür) und solche nervigen Antworten
  3. Sie erhalten in einer hilfreichen Zeit keine Antwort auf Ihre Frage. Wenn Sie in weniger als 7 Tagen eine Antwort erhalten, sollten Sie sich selbst hier glücklich schätzen StackOverflow

Ich hoffe immer, dass jemand anfängt, die JDOSpezifikation selbst zu implementieren . Vielleicht bietet er der Community dann mehr und hoffentlich mehr freie Aufmerksamkeit und Datanucleuskümmert sich nicht immer darum, für Support bezahlt zu werden, und sagt nicht, dass sich Autoren nur um kommerziellen Support kümmern , aber ich sage nur.

Ich persönlich bin der Meinung, dass DatanucleusAutoren keinerlei Verpflichtung gegenüber sich Datanucleusselbst oder ihrer Gemeinschaft haben. Sie können das gesamte Projekt jederzeit fallen lassen und niemand kann sie dafür beurteilen, es ist ihre Anstrengung und ihr eigenes Eigentum. Aber Sie sollten wissen, worauf Sie sich einlassen. Sie sehen, wenn einer von uns Entwicklern nach einem Framework sucht, das verwendet werden kann, können Sie den Autor des Frameworks nicht bestrafen oder befehlen, aber andererseits müssen Sie Ihre Arbeit erledigen! Wenn Sie Zeit hätten, dieses Framework zu schreiben, warum würden Sie überhaupt nach einem suchen?!

Auf der anderen Seite JDOhat es einige Komplikationen wie den Lebenszyklus von Objekten und Dinge, die nicht sehr intuitiv und häufig sind (glaube ich).

Bearbeiten: Jetzt weiß ich, dass auch JPAder Objektlebenszyklusmechanismus erzwungen wird. Es scheint also unvermeidlich, sich mit Lebenszykluszuständen persistierter Entitäten zu befassen, wenn Sie eine Standard-ORM-API verwenden möchten (dh JPAoder JDO).

Was mir am besten gefällt, JDOist die Möglichkeit, ohne großen Aufwand mit JEDEM Datenbankverwaltungssystem zu arbeiten.

Muhammad Gelbana
quelle
Sie haben bei fast jeder Beobachtung Recht. ORM ist ein Ärgernis für einige komplexe persistente Objekte (Monate des Debuggens buchstäblich!). Derzeit bin ich mit DN 2.1 festgefahren, weil eine Eigenschaft geändert wurde und mein Code mit neueren Versionen nicht funktioniert. Trotzdem ist DN mit JDO meiner Meinung nach der richtige Weg.
marcolopes
3

GAE / J wird voraussichtlich vor Jahresende MYSQL hinzufügen.

Stanlick
quelle
2
Hast du eine Quelle dafür?
Taylor Leese
1
Downvoted, weil ich nicht denke, dass dies wahr ist, keine Informationen online finden kann, um dies zu unterstützen, und es gibt keine Beweise für den Beitrag.
Steve Armstrong
3
Die Roadmap erwähnt eine voll funktionsfähige SQL-Datenbank im Werkscode.google.com/appengine/business/roadmap.html
Ashwin Prabhu
Witzig, aber jetzt (31.08.2011) haben wir festgestellt, dass es überhaupt nicht stimmt.
Magallanes
1
Nicht wahr? Die Beta-URL der App Engine SQL Preview (Beta) von Google ist ziemlich lang, daher habe ich sie auf goo.gl/AhsxX gekürzt ( ich dachte, es muss erklärt werden, falls Sie nicht glauben ).
Big Rich
1

JPA ist der richtige Weg, da es als standardisierte API vorangetrieben zu werden scheint und kürzlich in EJB3.0 an Dynamik gewonnen hat. JDO scheint den Dampf verloren zu haben.

Prateek Mathur
quelle
1

Weder!

Verwenden Sie Objectify, weil es billiger ist (weniger Ressourcen verbraucht) und schneller ist. Zu Ihrer Information: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify ist eine Java-Datenzugriffs-API, die speziell für den Google App Engine-Datenspeicher entwickelt wurde. Es nimmt einen "Mittelweg" ein; einfacher zu verwenden und transparenter als JDO oder JPA, aber wesentlich bequemer als die Low-Level-API. Objectify wurde entwickelt, um Anfänger sofort produktiv zu machen und gleichzeitig die volle Leistung des GAE-Datenspeichers zu nutzen.

Mit Objectify können Sie Ihre eigenen typisierten Objekte beibehalten, abrufen, löschen und abfragen.

@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);
Daniel De León
quelle
ist dies nur für den Datenspeicher? Wie wäre es mit Cloud SQL?
Zeitlos
1
Und der Nachteil ist, dass Sie eng mit dem Anbieter verbunden sind. Nicht immer ein Problem, aber der springende Punkt bei JDO ist, dies zu vermeiden. (Sprechen als derjenige, der es wahrscheinlich für kleine Dienste verwenden wird).
Pijusn