JDO vs JPA dla Java w Google App Engine

81

Chcę rozwijać swój projekt w Google App Engine za pomocą Struts2. Do bazy danych mam dwie opcje JPA i JDO. Czy możecie mi to zasugerować? Obie są dla mnie nowe i muszę się ich nauczyć. Więc skupię się na jednym po twoich odpowiedziach.

Dzięki.

Tahir Akram
źródło

Odpowiedzi:

32

JPA jest standardem wytrwałości firmy Sun, JDO to umieranie IMHO (właściwie jest martwe, ale wciąż się porusza). Innymi słowy, WZP wydaje się lepszą inwestycją w perspektywie długoterminowej. Więc myślę, że wybrałbym JPA, gdyby oba były dla mnie nowe.

Pascal Thivent
źródło
52
JDO nie umiera i jest skierowane do innej grupy odbiorców. Proszę sprawdzić swoje fakty. JDO miało JDO 2.1, JDO 2.2, a teraz JDO 2.3. JDO jest niezależne od magazynu danych. JPA jest przeznaczony wyłącznie dla RDBMS. Fakt
DataNucleus
17
Cóż, nie sądzę, abyśmy mogli powiedzieć, że przyjęcie JDO zakończyło się sukcesem, bez względu na to, ile jest wersji. Otwórz oczy, JDO może mieć miliardy wersji, i tak nikt go nie używa (i proszę, nie mów mi, że JDO odrodzi się dzięki GAE). Następnie, jeśli JPA jest przeznaczony wyłącznie dla RDBMS, wyjaśnij mi, dlaczego możemy używać tego interfejsu API z BigTable Google? Dzięki.
Pascal Thivent
10
Chłopaki, jeśli Google to wybrał, to nie umiera. Wiedzą, co robią. Przy okazji, Gratulacje @DataNucleus. Widziałem, jak wybierają twoją implementację.
santiagobasulto
6
To zła odpowiedź. JPA jest specyficzne dla Rdbms. Dlatego nie można go używać w przypadku masowego rozprzestrzeniania się alternatywnych magazynów danych (tak zwanych NoSQL), które widzieliśmy w ostatnich latach. Przynajmniej bez brzydkich kompromisów. Dlatego proszę nie oznaczać „JPA is daed” jako poprawnej odpowiedzi
smartnut007
2
Nigdy nie należy wybierać opcji na podstawie popularności. Cała platforma GAE jest oparta na dużym stole i do tego służy JDO!
FUD
33

Grupa Google GAE / J ma kilka postów na ten temat. Szukałem tam i patrzyłem na opinie ludzi. Otrzymasz zupełnie inny przekaz niż opinie wyrażone powyżej. Skoncentruj się również na fakcie, że BigTable nie jest systemem RDBMS. Użyj odpowiedniego narzędzia do pracy

DataNucleus
źródło
3
Dlaczego Google App Engine obsługuje JPA w swoim magazynie danych BigTable za pomocą wtyczki datanucleus-appengine (cytując datanucleus.org/products/accessplatform/appengine/support.html ), jeśli jest to całkowity błąd? Czy możesz to rozwinąć?
Pascal Thivent
16
Obsługa JPA w magazynach danych innych niż RDBMS wiąże się z kompromisami w zakresie interfejsu API i języka zapytań. Wiele rzeczy nie pasuje, więc nie są obsługiwane, ponieważ są specyficzne dla RDBMS (na przykład znaczące części JPQL lub wiele adnotacji JPA itp.). W związku z tym nie można mieć pełnej przenośności między magazynami danych, a więc każdy argument przemawiający za używaniem JPA na BigTable będącym prostą kopią tego, czego używałbyś dla magazynu RDBMS, jest fałszywy.
DataNucleus,
6
Z drugiej strony dla JDO język zapytań (JDOQL) nie ma komponentów specyficznych dla RDBMS, a metadane są ogólnie neutralne dla bazy danych, a komponenty specyficzne dla RDBMS są wyraźnie oddzielone. W konsekwencji masz możliwość przenoszenia między magazynami danych. JDO API pozwala na użycie natywnego języka zapytań dla każdego magazynu danych, jeśli jest to wymagane.
DataNucleus
9
Nigdy nie powiedziałem, że możesz używać pełnego API JPA, ale dla mnie to nie przeszkodzi ci w ponownym wykorzystaniu wiedzy o JPA, więc nie jest to po prostu uzasadniony powód, aby nie używać JPA. A tak przy okazji, przenoszenie w magazynach danych nie występuje w prawdziwym życiu .
Pascal Thivent
4
Cokolwiek powiem, nie zgodzisz się, więc dyskusja nie ma sensu, ani nie jest konieczna. Tak, przenoszenie między magazynami danych zdarza się, ponieważ mam klientów, którzy właśnie to robią. Jak zawsze ludzie powinni sami decydować o swoich potrzebach projektowych, o czym mówimy w dokumentacji DataNucleus. --Andy (DataNucleus)
DataNucleus
24

Właśnie zobaczyłem porównanie JPA i JDO przez samych DataNucleus: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Otwierający oczy.

Vinod
źródło
3
Ten manifest Datanucleus wydaje się być bardzo pro-JDO. Wszystkie ich wypowiedzi wydają się krytyczne wobec JPA i obronne wobec JDO, a jednak uważam, że używanie JPA jest przyjemniejsze niż używanie JDO.
Blessed Geek
8
DataNucleus obsługuje zarówno JDO, jak i JPA, a większość JPA2 została właśnie uwzględniona w DN 2.0. Promujemy oba, w przeciwieństwie do wszystkich innych rozwiązań trwałości, i pozwalamy użytkownikom wybrać. Jeśli uważasz, że w jakimkolwiek opisie JDO lub JPA są błędy rzeczowe, z radością przyjmiemy Twój wkład. Jeśli jesteś częścią programu politycznego w twoim imieniu, najlepiej zachowaj swoje uczucia dla siebie
DataNucleus
16

Jestem szczęśliwym użytkownikiem JDO. Kontynuujcie dobrą robotę.

Manfred
źródło
2
Jestem szczęśliwym użytkownikiem JDO: dobrze mi odpowiada, kiedy się do tego przyzwyczaiłem. Ponadto dzięki JDO mam możliwość odejścia od GAE / J i Google BigTable bez całkowitego przeprojektowywania mojej trwałej wymiany danych.
Ian Marshall
12

Ludzie twierdzący, że JDO nie żyje, nie są pozbawieni zasług. Oto, co przeczytałem w książce Pro EJB 3 Java Persistence API: „Wkrótce potem firma Sun ogłosiła, że ​​JDO zostanie zredukowane do trybu konserwacji specyfikacji i że Java Persistence API będzie czerpać zarówno z JDO, jak i innych dostawców trwałości i stanie się jedynym obsługiwanym standard w przyszłości. ”. Autor Mike Keith jest liderem specyfikacji w EJB3. Oczywiście jest wielkim zwolennikiem JPA, ale wątpię, czy jest na tyle stronniczy, by kłamać.

Prawdą jest, że kiedy książka została opublikowana, większość głównych dostawców była zjednoczona za JPA, a nie za JDO, mimo że JDO ma bardziej zaawansowane funkcje techniczne niż JPA. Nie jest to zaskakujące, ponieważ duzi gracze w świecie EE, tacy jak IBM / Oracle, są również dużymi dostawcami RDBMS. Więcej klientów używa w swoich projektach RDMBS niż innych niż RDMBS. JDO umierał, dopóki GAE nie przyspieszyło. Ma to sens, ponieważ magazyn danych GAE nie jest relacyjną bazą danych. Niektóre funkcje JPA nie działają z tabelami bigtable, takimi jak zapytania agregujące, zapytania typu Join, posiadane relacje „wiele do wielu”. BTW, GAE obsługuje JDO 2.3, podczas gdy obsługuje tylko JPA 1.0. Polecę JDO, jeśli GAE jest Twoją docelową platformą chmurową.

przypływ
źródło
11

Dla przypomnienia jest to Google App Engine (GAE), więc gramy z regułami Google, a nie regułami Oracle / Sun.

Pod nim JPA nie nadaje się do GAE, jest niestabilny i nie działa zgodnie z oczekiwaniami. Ani Google nie chce go wspierać, ale absolutne minimum.

Z drugiej strony JDO jest dość stabilny w GAE i jest (w pewnym stopniu) dobrze udokumentowany przez Google.

Jednak Google nie poleca żadnego z nich.

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

Niskopoziomowy interfejs API zapewnia najlepszą wydajność, a GAE polega na wydajności.

http://gaejava.appspot.com/

Na przykład dodaj 10 jednostek

Python: 68 ms

JDO: 378 ms

Java Native: 30 ms

magallanes
źródło
Nie takie wyniki otrzymuję, przeprowadzając testy.
code511788465541441
9

W wyścigu między JDO a JPA mogę tylko zgodzić się z plakatami datanucleus.

Przede wszystkim, i co najważniejsze, plakaty jądra danych wiedzą, co robią. W końcu rozwijają trwałą bibliotekę i znają inne niż relacyjne modele danych, np. Big Table. Jestem pewien, że gdyby był tutaj programista zajmujący się hibernacją, powiedziałby: „wszystkie nasze założenia podczas budowania naszych podstawowych bibliotek są ściśle powiązane z modelem relacyjnym, hibernacja nie jest zoptymalizowana pod kątem GAE”.

Po drugie, JPA jest niewątpliwie w bardziej powszechnym użyciu, będąc częścią oficjalnego stosu Java EE trochę pomaga, ale niekoniecznie oznacza to, że jest lepszy. W rzeczywistości JDO, jeśli o tym czytasz, odpowiada wyższemu poziomowi abstrakcji niż JPA. JPA jest ściśle powiązany z modelem danych RDBMS.

Z programistycznego punktu widzenia korzystanie z interfejsów API JDO jest znacznie lepszą opcją, ponieważ koncepcyjnie mniej kompromisów. Teoretycznie można przełączyć się na dowolny model danych według własnego uznania, pod warunkiem, że używany dostawca obsługuje bazową bazę danych. (W praktyce rzadko uzyskujesz tak wysoki poziom przejrzystości, ponieważ zdarzy się, że ustawiasz swoje klucze główne na obiekcie GAE i będziesz wiązał się z konkretnym dostawcą bazy danych, np. Google). migracja będzie jednak nadal łatwiejsza.

Po trzecie, możesz używać Hibernate, Eclipse Link, a nawet sprężyny z GAE. Wygląda na to, że Google poczynił duży wysiłek, aby umożliwić Ci korzystanie z frameworków, na których jesteś przyzwyczajony do tworzenia aplikacji. Ale ludzie zdają sobie sprawę, kiedy budują swoje aplikacje GAE tak, jakby działały na RDBMS, że są powolne. Wiosna na GAE jest powolna. Możesz wygooglować filmy Google IO na ten temat, aby zobaczyć, że to prawda.

Poza tym przestrzeganie standardów jest rozsądną rzeczą, którą w zasadzie oklaskuję. Z drugiej strony, JPA będąc częścią stosu Java EE sprawia, że ​​ludzie czasami tracą pojęcie o opcjach. Zrozum, jeśli chcesz, że Java Server Faces jest również częścią stosu Java EE. Jest to niewiarygodnie uporządkowane rozwiązanie do tworzenia internetowego interfejsu GUI. Ale ostatecznie, dlaczego ludzie, mądrzejsi ludzie, jeśli mogę tak powiedzieć, odchodzą od tego standardu i zamiast tego używają GWT?

W tym wszystkim muszę się przekonać, że JPA ma jedną bardzo ważną rzecz. To jest Guice i jego wygodna obsługa JPA. Wygląda na to, że Google nie był tak sprytny jak zwykle w tym momencie i jest zadowolony, na razie nie obsługując JDO. Nadal myślę, że ich na to stać i ostatecznie Guice pochłonie również JDO, ... a może nie.

99Sono
źródło
6

Idź JDO. Nawet jeśli nie masz w tym doświadczenia, nie jest trudno go podnieść, a będziesz miał nową umiejętność pod pasem!

corydoras
źródło
6

To, co uważam za okropne w używaniu tego JDOw momencie pisania, to fakt, że jedynym dostawcą wdrożeń jest, Datanucleusa jego wadą jest brak konkurencji, który prowadzi do wielu problemów, takich jak:

  1. Niezbyt szczegółowa dokumentacja dotycząca niektórych aspektów, takich jak extensions
  2. Zwykle otrzymujesz sarkastyczne odpowiedzi od autorów, takie jak (Czy sprawdzałeś logi? Może jest powód, dla którego je masz) i irytujące odpowiedzi takie jak te
  3. Nie otrzymujesz odpowiedzi na swoje pytanie w pożytecznym czasie, czasami, jeśli otrzymasz odpowiedź w mniej niż 7 dni, powinieneś uważać się za szczęściarza, nawet tutaj StackOverflow

Zawsze mam nadzieję, że ktoś sam zacznie wdrażać JDOspecyfikację, może wtedy zaoferuje społeczności coś więcej i miejmy nadzieję, że będzie miał więcej darmowej uwagi i nie zawsze będzie zawracać sobie głowę zapłatą za wsparcie, nie mówiąc tegoDatanucleus autorom zależy tylko na wsparciu komercyjnym , ale ja tylko mówię.

Osobiście uważam, że Datanucleusautorzy nie mają żadnych zobowiązań wobec Datanucleussiebie ani swojej społeczności. W każdej chwili mogą zrezygnować z całego projektu i nikt nie może ich za to oceniać, to ich wysiłek i własna własność. Ale powinieneś wiedzieć, w co się pakujesz. Widzisz, gdy jeden z nas programistów szuka frameworka do użycia, nie możesz ukarać ani rozkazać autorowi frameworka, ale z drugiej strony musisz wykonać swoją pracę! Gdybyś miał czas na napisanie tego frameworka, dlaczego miałbyś go w ogóle szukać ?!

Z drugiej strony JDOsamo w sobie ma pewne komplikacje, takie jak cykl życia obiektów i rzeczy, które nie są zbyt intuicyjne i powszechne (tak mi się wydaje).

Edycja: Teraz wiem, że JPAwymusza również mechanizm cyklu życia obiektu, więc wygląda na to, że nieuniknione jest radzenie sobie ze stanami cyklu życia trwałych jednostek, jeśli chcesz użyć standardowego interfejsu API ORM (tj. JPALub JDO)

Najbardziej podoba mi JDOsię możliwość pracy z DOWOLNYM systemem zarządzania bazą danych bez większego wysiłku.

Muhammad Gelbana
źródło
Masz rację co do prawie każdej obserwacji. ORM to wrzód na dupie dla niektórych złożonych, trwałych obiektów (miesiące debugowania, dosłownie!). Obecnie utknąłem na DN 2.1, ponieważ właściwość została zmieniona i mój kod nie będzie działał z nowszymi wersjami. To powiedziawszy, moim zdaniem DN z JDO jest najlepszym rozwiązaniem.
marcolopes,
3

GAE / J ma dodać MYSQL przed końcem roku.

stanlick
źródło
2
Czy masz źródło tego?
Taylor Leese,
1
Negocjowano, ponieważ nie sądzę, że to prawda, nie mogę znaleźć żadnych informacji w Internecie, aby to wesprzeć, i nie ma żadnych dowodów dołączonych do postu.
Steve Armstrong
3
Mapa drogowa wspomina, że ​​w pełni funkcjonalna baza danych SQL znajduje się w pliku
Ashwin Prabhu
Zabawne, ale teraz (31-08-2011) okazało się, że to w ogóle nieprawda.
magallanes
1
Nie prawda? URL Google App Engine SQL Preview (beta) jest dość długi, więc skróciłem go goo.gl/AhsxX (pomyślałem, że trzeba to wyjaśnić na wypadek, gdybyś nie wierzył).
Big Rich,
1

JPA jest drogą do zrobienia, ponieważ wydaje się być popychane jako standaryzowane API i ostatnio nabrało rozpędu w EJB3.0 .. Wydaje się, że JDO stracił parę.

prateek mathur
źródło
1

Ani!

Użyj Objectify, ponieważ jest tańszy (zużywa mniej zasobów) i jest szybszy. FYI: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify to interfejs API dostępu do danych w języku Java, zaprojektowany specjalnie dla magazynu danych Google App Engine. Zajmuje „środek”; łatwiejsze w użyciu i bardziej przejrzyste niż JDO lub JPA, ale znacznie wygodniejsze niż Low-Level API. Objectify ma na celu natychmiastowe zwiększenie produktywności nowicjuszy, a jednocześnie ujawnienie pełnej mocy magazynu danych GAE.

Objectify pozwala utrwalać, pobierać, usuwać i wysyłać zapytania do własnych wpisanych obiektów.

@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
źródło
czy to tylko dla datastore? a co z chmurą SQL?
Timeless
1
Wadą jest to, że jesteś mocno związany ze sprzedawcą. Nie zawsze jest to problem, ale celem JDO jest uniknięcie tego. (mówi jako ten, który prawdopodobnie użyje go do małych usług).
Pijusn